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TECHNICAL FIELD 

1 This invention relates to professional data management 

2 systems useful in the production of product specif icatior. 

3 documents such as prescriptions, service or parts orders, 

4 insurance contracts and the like that require detailed 

5 product and history information from multiple extensive 

6 information sources, especially remote heterogenous sources. 

7 More particularly, the invention relates to systems that 

8 assist professionals perform their everyday work in 

9 specifying customized technical products. A particularly 

10 preferred embodiment relates to a computer-implemented 

11 prescription management system to assist physicians in 

12 prescribing and reviewing drugs. 
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1 BACKGROUND 

"2 An important professional activity undertaken by most 

3 physicians during the course of their day is the prescribing 

4 of drugs. Many physicians prescribe a great number of drugs 

5 every day. Studies show that over two thirds of all doctor- 

6 patient encounters were completed with the writing of a 

7 prescription. In 1993 typical prescribers were prescribing 

8 in excess of two hundred thousand dollars-worth of drugs 

9 annually. While most physicians exercise the utmost of 

10 professional skill and caution in prescribing, there are 

11 inherent difficulties and uncertainties in the process. 

12 Most physicians will probably agree that they do not have 

13 access to adequate, reliable drug information and relevant 

14 patient information az the time and point of prescription. 

15 In particular, information regarding relevant new drugs, 

16 comparative efficacy, and importantly, relative costs, may 

17 not be readily and conveniently available to a physician 

18 creating a new prescription, as well as relevant patient 

19 information such as current conditions being treated, 

20 current treatments, and preferred medications for 

21 conditions, pursuant to requirements of the patient ! s drug 

22 formulary. 
23 

24 Nevertheless, while accessing it is impractical f or_ the 

25 typical practitioner, such information is available to any 

26 physician willing to take the time and make the effort to 
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1 obtain it. 

"2 

3 In contrast, integrated patient-specific information which 

4 is directly relevant to treatment management for the subject 

5 patient is frequently both unavailable to, and unobtainable 

6 by, a prescribing physician unless that physician's 

7 institution or organization has been exhaustively 

8 responsible for the subject patient's prior care and 

9 maintains sophisticated computerized records. Information 

10 as to allergies, current prescriptions and currently active 

11 conditions is clearly desirable or essential for intelligent 

12 prescribing. In 1994, few prescribing sessions are 

13 conducted with the benefits of integrated patient-specific 

14 information and fewer still have the benefit of specific 

15 drug formulary recommendations on the subject patient. 
16 

17 Typically, drug formularies comprise lists of preferred 

18 drugs whose costs will be borne by a drugs benefit house. 

19 Drug formulary information is usually determinative of the 

20 cost-effectiveness of a prescription. Unwitting failure by 

21 a prescriber to follow formulary guidelines can impose 

22 . unnecessary or unexpected cost burdens on the patient, or 

23 their benefits provider, and lead ' to poor patient compliance 

24 and aggravating and time-consuming disputes. The cost in 

25 dollars of non-compliance with drug formulary guidelines to 

26 benefit-providing corporations, insurers, health maintenance 
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1 organizations and government providers, for example MEDICAID 

2 and MEDICARE, can be enormous. The cost of poor patient 

3 compliance may ultimately increase the total cost of care by 

4 generating a more serious, expensive adverse health outcome 

5 ( emergency room visit, or hospital admission or death) . 
6 

7 A difficulty in making integrated patient-specific 

8 information readily available to prescribing professionals 

9 is that the needed information components are not 

10 centralized but are widely distributed geographically and 

11 even when their geographic or electronic locations are 

12 known, are hard to access because of proprietary and 

13 liability and patient-confidentiality concerns and because 

14 of system, file or protocol incompatibilities. 
15 

16 Even in the computer-abundant United States, in the mid- 
17 90' s, prescription writing is generally a manual process. 

18 After consulting with a patient to determine their problems 

19 and diagnosing, or attempting to diagnose their condition or 

20 disease, a physician selects a drug and a dosage and an 

21 amount to prescribe based upon their own personal knowledge 

22 and experience, if necessary using available reference 

23 materials which may or may not include promotional materials 

24 from drug manufacturers. A prescription is then written up 

25 under the physician's signature and bears a patient 

26 identification, a drug name, dosage amount and timing, 
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1 ref inability information and the physician's signature, the 

"2 date, possibly an advisory regarding contraindications, and 

3 little other information. While a prescription may be 

4 typed, keyed or otherwise "generated" on a computer most 

5 prescriptions are still manually written. 
6 

7 Prescribing activity should be a good field for 

8 computerization, but one difficulty is the lack of apparent 

9 benefits to many physicians. Paper prescription pads are 

10 small and easily carried around by a physician. Manually 

11 writing a prescription will often be quicker and easier than 

12 using a computer, however good the system. The benefits of 

13 automated information systems often come not from greater 

14 data entry efficiency, but from the increased efficiency of 

15 the entire process, from the value of the transaction 

16 records generated and also from the control of the 

17 transaction entry process which may ensue. Physicians who 

18 are not computer-literate or who are even "computer-phobic" 

19 will require a most compelling reason to adopt a 

20 computerized prescription management system. 
21 

22 To be fully effective, a prescription management system must 

23 be readily usable by a wide range of physicians, preferably 

24 for all their prescribing activity must provide compelling 

25 value to patient care and increase overall treatment 

26 management efficiency. Providing an attractive computer- 
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1 based system to physicians is fraught with unexpected 

2 difficulties . 
3 

4 Physicians and other health care professionals, especially 

5 those with prescribing authority, are representative of 

6 certain groups of professionals whose unique characteristics 

7 raise obstacles to the computerization of their day-to-day 

8 professional activities. Desirably, a computerized 

9 professional management system should be capable of flexible 
10 integration into their personalized and varied work flows. 
11 

12 Contrary to many perceptions and assumptions in conventional 

13 data-management systems intended for use by physicians, 

14 clinical physicians are not deskbound workers and do not 

15 usually have continuous access to a personal desktop 

16 computer during the course of their normal daily routine. 

17 To the contrary most physicians are ambulatory or even 

18 highly mobile, moving from room to room, from office to 

19 office, from hospital to hospital and to and from their car 

20 and home. While some physicians may spend the majority of 

21 their health care patient encounter activities at or near a 

22 desktop in their own office, such physicians are probably 

23 the exception. In clinics and hospitals physicians are 

24 often continually on the move between examination rooms, 

25 reception areas, administrative centers, hospital wards, 

26 specialist facilities such as radiology rooms and so on and 
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1 so forth. In addition many physicians have more than one 

2 practice or more than one professional activity which takes 

3 them between an office or clinic and a hospital or other 

4 facility on a regular basis. Accordingly, it is a 

5 significant technical challenge to provide such mobile 

6 physicians with access to a computer-implemented management 

7 system that is readily available at the point of care. 
8 

9 Portable computers are a possible solution to the access 

10 problem now that powerful and compact notebook computers are 

11 widely available. Although currently available portable 

12 computers offer some advantages particularly to physicians 

13 moving between one work place and another, they also suffer 

14 certain drawbacks. Cne drawback is that external 

15 communication is difficult being commonly effected by moving 

16 diskettes, a valuable bur limited method, or by modem 

17 connection to a telephone line which inconveniently requires 

18 plugging into a wall jack. Though possibly adequate for a 

19 physician having multiple offices, neither the communication 

20 means nor the portability of such systems is satisfactory 

21 for a ward physician moving from patient bed to patient 

22 bed. The weights and form factors of traditional portable 

23 computers are severe impediments to their assimilation into 

24 many clinical physicians 1 daily lives as dependable _ 

25 assistants to their professional work. 
26 
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1 More recently, small handheld cr palm computers known as 

2 personal digital assistants or personal information 

3 communicators have become available. An example is the 

4 Apple NEWTON (trademark). As of summer 1994, these are 

5 rather rudimentary devices as compared with desktop or full- 

6 powered portable systems, having modest permanent and RAM 

7 storage capacities and limited processing and communications 

8 abilities. Attractive to busy mobile professionals for 

9 their small size, such handheld computers can also embody 

10 highly desirable radio wave or infrared wireless 

11 communications abilities enabling them to exchange data with 

12 host systems without the cost or inconvenience of hard 

13 wiring. 
14 

15 Such portable hand held radio communicating computing 

16 devices are attractive for computerizing mobile 

17 professionals such as physicians, but their processing and 

18 storage limitations represent a real problem in providing a 

19 sophisticated, capable and attractive system for physicians. 
20 

21 A broad objective of this invention is to provide a 

22 prescription management system that can be used by 

23 physicians on such mobile computing devices. 
24 

25 Simply delivering a system on a convenient portable computer 

26 will not be enough to assure its regular use by a majority 
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1 of physicians. Though highly educated and technically 

2 skilled, many physicians are not computer literate and are 

3 averse to confronting a computer screen. Some may even be 

4 intimidated by computers. Nor do their busy schedules 

5 permit time to learn complex or difficult systems. Even for 

6 an experienced user adoption of computer use into their 

7 daily routines requires time change and adaptation. With 

8 tremendous competition for their time, physicians will only 

9 be willing to take these steps if they are enticed by 

10 powerful system features that provides them with compelling 

11 value to patient care and overall practice management 

12 efficiency. 
13 

14 Nevertheless, the greatest of system features will be 

15 worthless if the system hinders the professional in 

16 executing routine functions. Even at sophisticated computer 

17 products companies with access to, and experience with, 

18 state-of-the-art systems, telephone sales staff often take 

19 down orders with pen and pad rather than using an on-line 

20 sales order systems. 
21 

22 An experienced professional practicing their specialty for 

23 example a pediatrician treating infants knows from 

24 experience exactly what to prescribe, in many instances. 

25 They will have neither the time nor the patience to work 

26 their way through conventional software selection and data 
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1 entry procedures. Accordingly, a further object of this 

2 invention is to provide a prescription management system 

3 which personalizes itself to the prescribing patterns of 

4 experienced users. 
5 

6 SUMMARY OF THE INVENTION 

7 This invention solves a problem. It solves the problem of 

8 providing a computerized, prescription management system 

9 that an average prescribing physician can use and will want 

10 to use and which makes possible significant improvements in 

11 the quality of prescriptions written. In preferred 

12 embodiments, the invention also solves the problem of 

13 significantly reducing prescription costs to patients and to 

14 their drugs benefit management company or government agency. 

15 The invention solves these problems for physicians by 

16 providing a prescription management system for electronic 

17 prescription creation by a prescriber at a point of patient 

18 care, said prescription being usable by a pharmacist to 

19 dispense drugs, said prescription management system 

20 comprising: 

21 a) electronic posting means to select and capture in said 

22 prescription: 

23 i) a patient identifier; 

24 ii) a prescribed drug; 

25 iii) a dosage for said prescribed drug; and 

26 b) a patient-condition treatment specification procedure; 
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1 whereby in creating said prescription said prescriber 

'2 specifies a patient condition for treatment by said 

3 prescribed drug. 
4 

5 More generally, the invention provides a computer-based 

6 professional product specification system for use by other 

7 professionals, in addition to physicians, which can deliver 

8 substantial benefits to mobile, users who may be computer- 

9 inexperienced. 
10 

11 By associating a patient condition or problem with each drug 

12 prescribed, a treatment objective is both expressed and 

13 recorded, .. .physician intent... and deliver for physicians 

14 the problem is solved by providing a user- friendly 

15 prescription management system, requiring minimal data entry 

16 enabling prescriptions to be created with an overall 

17 efficiency unobtainable by any known automated system and 

18 which can helpfully supplement the skills of the best of 

19 practitioners. 
20 

21 Pursuant to one preferred embodiment of the invention, the 

22 drugs in the drug list are classified according to a patient 

23 condition for which the drugs are effective and the onscreen 

24 drug selection procedure lists multiple drugs for treating 

25 each patient problem. In an alternative embodiment, the 

26 user makes a drug selection by generic or brand name or some 
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1 other drug identifier, and the system supplies, suggests or 

"2 requires, entry of an appropriate treatment condition so 

3 that the patient record is completed with the condition or 

4 conditions for which the selected drug is prescribed. 
5 

6 The invention also provides a user-adaptive prescription 

7 management system for electronic prescription creation by a 

8 prescriber at a point of patient care, said prescription 

9 being usable by a pharmacist to dispense drugs, said 

10 prescription management system comprising: 

11 a) electronic posting means to select and capture in said 

12 prescription: 

13 i) a patient identifier; 

14 ii) a prescribed drug; 

15 iii) a dosage for said prescribed drug; 

16 b) a patient-condition treatment specification procedure 

17 whereby in creating said prescription said prescriber 

18 specifies a patient condition for treatment by said 

19 prescribed drug; 

20 c) an onscreen drug selection procedure having a patient 

21 condition list specifying multiple possible patient 

22 conditions, having a drug list specifying multiple 

23 possible prescribable drugs and having drug 

24 specification means to select and post a desired drug 

25 to said prescription; and 

26 d) tracking means to track preferred data usage by a user 
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1 and to adapt data displays to favor such preferred 

"2 usage, whereby the system learns and adapts to a user's 

3 habits; 

4 wherein drugs in said drug list are classified according to 

5 a patient condition for which said drugs have efficacy and 

6 said onscreen drug selection procedure lists multiple drugs 

7 for treating each said patient problem. 
8 

9 Drug lists or individual drug selections or suggestions may 

10 be presented to prescriber-users in any of a variety of ways 

11 for example by frequency of prescription for a selected 

12 condition, based upon either the user's historical 

13 prescription activity or a wider base of historical 

14 prescribing activity, which could be nationally or 

15 regionally defined or derived from a drugs benefit house, 

16 health maintenance organization, hospital or other 

17 appropriate institution, 
18 

19 System suggestions for condition-related drug selection may 

20 be further refined into categories such as relative cost, 

21 generic or brand name and so on. Where many drugs are 

22 available for treating a patient's active condition, one 

23 particularly useful presentation is by multiple lines of 

24 therapeutic preference according to drug formulary 

25 guidelines. Thus, within the patient's particular formulary 

26 there may be suggested first, second and third lines of 
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1 therapy- Different suggestions may be made for different 

"2 patients according to the preferences of the patient's 

3 particular drugs benefit management company. 
4 

5 Preferably the system includes a comprehensive database of 

6 approved drugs classified by conditions for which they are 

7 known to have therapeutic effect and this database need not 

8 be maintained in the users station but should be accessible 

9 in real time to the user. Many valuable professional 

10 benefits are obtained by delivering a selective listing of 

11 drugs by condition to a physician. For example in treating 

12 a particular chronic condition such as gastro-intestinal 

13 disease, a physician may find that common medicaments such 

14 as antacids are ineffective, that a particular brand name 

15 drug such as TAGAMET (trademark) has, with prolonged use, 

16 undesired side effects so that the physician may at this 

17 point be interested in gaining information about alternative 

18 drugs with which they are less familiar. If the physician 

19 does not have the information at their finger tips, this 

20 could be a time consuming process in their office reviewing 

21 files and other archival information systems they have. 

22 Alternatively on-line electronic services may be used but 

23 this can also be a time consuming process. By offering a 

24 comprehensive selection of drugs known to be effective for a 

25 particular condition, this problem is easily solved for the 

26 physician. The preferred embodiments include back-up 
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1 prescribing information on each drug, along with details of 

"2 literature references supporting its manufacturer's 

3 therapeutic claims or with means enabling the physician 

4 promptly to obtain such references. 
5 

6 The invention is not limited to providing a prescription 

7 management system. It can provide, in the medical field 

8 alone, systems for clinical laboratory management, for 

9 medical record management for radiology management and the 

10 like. In addition the invention can provide novel 

11 professional data management systems that can create new 

12 products and yield comparable benefits in other professional 

13 spheres where professionals aic responsible for specifying 

14 more or less complex technical products to solve client or 

15 customer problems, 
16 

17 In this wider aspect the invention provides a professional 

18 product specification system for electronically creating a 

19 technical specification usable by a professional to specify 

20 technical products said product specification system 

21 comprising: 

22 a) electronic posting means to select and capture in said 

23 technical specification: 

24 i) a customer identifier; 

25 ii) a specified product; and 

26 b) an onscreen product selection procedure having a 
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1 product benefit list specifying multiple possible 

"2 customer benefits having a product list specifying 

3 multiple possible specifiable products and having 

4 product specification means to select and post a 

5 desired product to said specification; 

6 wherein products in said product list are classified 

7 according to a customer benefit which said products can 

8 provide and said onscreen product selection procedure lists 

9 multiple products for providing each said customer benefit. 
10 

11 BRIEF DESCRIPTION OF THE DRAWINGS 

12 By way of example, some preferred embodiments of the 

13 invention are described in detail below with reference to 

14 the accompanying drawings in which :- 
15 

16 Figure 1 shows a system entry screen of a prescription 

17 management system embodiment of the invention 

18 which system incorporates the screens of 

19 Figures 2-11; 

20 Figure 2 is a patient selection screen; 

21 Figure 3 shows a prescription creation screen; 

22 Figure 4 is a condition list selection screen; 

23 Figure 5 is a condition selection screen; 

24 Figure 6 is a drug selection screen, condition 

25 specified; 

26 Figure 7 is a nonformulary drug selection screen; 
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1 Figure 8 is an alternative condition-specification and 
'2 drug selection screen; 

3 Figure 9 is an alternative direct drug specification 

4 screen; 

5 Figure 10 is a condition selection screen, drug 

6 specified; 

7 Figure 11 is a drug selection evaluation screen; 

8 Figure 12 is a single prescription history screen. 

9 Figure 13 is a patient problem history information 

10 screen; and 

11 Figure 14 is a manually updatable problem list 

12 maintenance screen; 

13 Figure 15 illustrates a scheduled dosage drug package; 

14 and 

15 Figure 16 is a schematic diagram of one way of 

16 connecting users of the prescription 

17 management system of Figures 1-14 with remote 

18 source databases across network to provide 

19 data and processing resources needed during 

20 operation of the prescription management 

21 system and useful inter alia for creation of 

22 a virtual patient record, 
23 

24 DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 



25 Overview 

26 The prescription management system illustrated in Figures 1- 
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1 14 can be provided in software for single-user operation on 

'2 a stand-alone personal computer for use, for example, by a 

3 sole practitioner or for multi-user operation on a local 

4 area network for use, for example, by physicians and other 

5 prescribers within a single facility, hospital, group 

6 practice, or the like prescribing organization, and the 

7 invention can bring substantial benefits to such users and 

8 their patients. 
9 

10 However, more significant benefits can accrue to patients, 

11 physicians, drug benefit providers and the public at large 

12 by implementation of the described prescription management 

13 system on a regional or nation-wide basis. To this end, a 

14 preferred embodiment of prescription management system 

15 comprises a host computer facility supporting wired or 

16 wireless network delivery of user-relevant components of 

17 said prescription management system to multiple remote user 

18 interface devices. 
19 

20 The host computer facility provides data, or access to data, 

21 data processing and communications resources for users to 

22 draw upon via the user interface devices. The host computer 

23 facility can be a server or cluster of servers with 

24 associated data storage volumes, and at least one 

25 intelligent client providing access to the server or 

26 servers. As will be explained in more detail hereinafter, 
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1 especially with reference to Figure 16, the host computer 

2 facility can call upon a variety of external resources and 

3 functions as a marshalling and processing center for 

4 organizing resources into useful and manageable pieces for 

5 utilization by limited capacity user-interface devices. In 

6 a preferred embodiment it is a co-ordination point on a 

7 network for a number of user-device clients. Preferably the 

8 network accesses or includes a number of remote database 

9 sources providing useful information elements to the system, 
10 

11 Referring to Figures 1 to 14 of the drawings, the screens 

12 shown employ user-friendly data selection and data entry 

13 devices such as are familiar zo many computer users in Apple 

14 Corporation's Macintosh© (trademark) and Microsoft 

15 Corporation's Windows operating systems, for example 

16 activatable buttons, pointers, scroll bars, icons, arrow 

17 key, drop-down menus, windows and other screen symbols 

18 designed for actuation by a pointing device, for example, a 

19 mouse or trackball. More preferably, for compact "pocket- 

20 book" computer applications, the pointing device is a pen or 

21 stylus. 
22 

23 The prescription management system shown in this embodiment 

24 of the invention has been designed for implementation on 

25 physically compact, portable, user-interface devices such as 

26 small portable personal computers, especially hand held 
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1 devices known as personal digital assistants. Those skilled 

*2 in the art will understand that the system can readily be 

3 used on or adapted to other hardware platforms, for example, 

4 a physician's desktop computer and can be expressed in 

5 different software interfaces from that shown, especially 

6 ones that use different input devices such as keyboards, 

7 touch pads or touch screens and the like. 
8 

9 Pursuant to certain user-adaptive aspects of this invention, 

10 the screens automatically personalize themselves, with use, 

11 to adopt the patterns and habits of a regular user of a 

12 particular device platform for the system, offering the user 

13 their most frequently used information, drugs, conditions , 

14 patients or patient groups, and so on as first line choices. 

15 This adaptive characteristic is a valuable benefit endearing 

16 the system to experienced users who may become impatient 

17 with hierarchically accessed data. 
18 

19 Ease of use and suitability of the system to keyless or 

20 minimally keyed platforms, especially PDA ! s is promoted by 

21 minimizing the need for actual text or data entry by the 

22 user and by emphasizing instead data selection from 

23 extensive, preferably comprehensive, data lists. Preferred 

24 embodiments of the invention allow quick pen selection of 

25 data items through columnar pick lists. 
26 
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1 The data lists, categories, groups, addresses or routes, can 

2 be organized in multiple hierarchies for rapid and flexible 

3 access to multiple large, remote databases, via multiple 

4 access routes to retrieve multiple related data elements and 

5 assemble them into a single data file, for example, a 

6 patient history file compiled from the data resources of a 

7 patient's historical health providers. 
8 

9 A desirable goal is to provide the physician-user with 

10 intelligent data lists that are, where possible, exhaustive 

11 and list, for example, all prescribable drugs, all 

12 conditions, all formularies or all patients and present the 

13 physician with helpful first-line choices or defaults 

14 selected intelligently on the basis of historical data known 

15 to the system. Preferably, the selection means is fully 

16 system embodied, or automatic, operating transparently to 

17 the user and requiring a minimum of conf igurational or setup 

18 operations by the user, 
19 

20 Virtual Patient Record 

21 An ability to compile what may be termed a "virtual" patient 

22 record from multiple remote databases of primary source 

23 information is a valuable novel feature of preferred aspects 

24 of this invention. Such a virtual patient record can be 

25 created in a chronologically current version by online 

26 interrogation of all possible primary sources of 
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1 electronically recorded patient history elements, by 

"2 retrieving those elements and assembling them into a 

3 complete record. Yet the record need neither be drawn from, 

4 nor committed to, permanent storage, obviating storage 

5 requirements for accumulations of patient records. 
6 

7 The record can be assembled dynamically, on an as-needed 

8 basis, consulted by an authorized system user, and then 

9 dissolved, without ever having been saved, giving the record 
10 a virtual character. 

11 

12 Record element retrieval and record assembly are conducted 

13 under the auspices of rhe host computer facility employing a 

14 novel patient data directory service providing routing 

15 information to each patient's record elements. For each 

16 patient, the patient data directory service lists all 

17 institutions, including independent physicians, hospitals, 

18 HMO's, insurance companies, and so on, known to have source 

19 historical records on that patient, against a unique patient 

20 identifier, such as described hereinbelow. Also listed are 

21 routing or address data enabling the host facility to access 

22 institutional databases to retrieve record elements. Access 

23 protocols detailing, for example, what data can be accessed, 

24 when it may be accessed, by whom or by what organization or 

25 department it may be accessed, can be kept in a patient- 

26 specified directory, or elsewhere. 
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1 Patients not listed in the directory service can be searched 

2 at the remote source databases and, optionally, at other, 

3 host computer facilities supporting the inventive system for 

4 other groups of users. 
5 

6 The complete, assembled patient history, or record, need 

7 never be stored, unless the patient requests or consents to 

8 such storage, and it serves some useful administrative or 

9 care-related function. Storage or archiving of a record 

10 that is potentially updatable from multiple uncoordinated 

11 locations has the drawback of daring it. To become current, 

12 the record must be refreshed from any database containing a 

13 new data element for that patient. 
14 

15 By using a dynamically assembled virtual record, and never 

16 storing it, potential problems of maintaining patient 

17 confidentiality and preventing unauthorized access to highly 

18 sensitive personal information can be mitigated or avoided. 

19 This aspect of the invention avoids proliferation of a 

20 patient's confidential history and permits primary source 

21 data proprietors to act as exclusive wardens of their 

22 individual confidential data elements. 
23 

24 Bio-pattern recognition 

25 Bio-pattern recognition of personal user characteristics 

26 including, for example, handwriting, signatures, voice 
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1 patterns and fingerprints is an attractive medium for 

2 accepting user inputs, but in the present state of 

3 development of the technology, suffers drawbacks which 

4 disfavor use of bio-pattern recognition in preferred 

5 embodiments of the invention. Future developments such as 

6 greater processing capabilities in small user-interface 

7 devices, and more accurate and efficient bio-pattern 

8 recognition techniques may change this picture and favor 

9 adoption of one or more forms of bio-pattern recognition. 
10 

11 Thus, handwriting recognition, is eschewed in preferred 

12 embodiments of the invention, at the present time, because 

13 writing is more tiresome to the user than pointing, pressing 

14 or clicking and adds complexity and processing overhead to 

15 the system. Additionally, handwriting recognition, although 

16 presently available in pioneer systems, adds uncertainties, 

17 may require significant user effort or adaptation and may 

18 threaten data accuracy or promote user error. 
19 

20 Signature recognition may be desirable, if permitted by 

21 regulatory agencies, for remote electronic authorization of 

22 fulfillment at the pharmacy especially for mail order 

23 prescription fulfillment and the pharmacy-prescriber link 

24 can, if desired, add additional levels of security by 

25 transmitting or exchanging supplemental electronic 

26 identifiers. 
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1 However, better security, in terms of ensuring that the 

2 filled prescription is released to the intended patient, or 

3 their agent, may by provided, by treating an electronic 

4 prescription transmission to a pharmacy as an advisory 

5 against which fulfillment may be initiated, while the 

6 prescription is released only in exchange for a manually 

7 signed hard (paper) copy. Signature recognition or 

8 transmission as an individual graphic element, insofar as it 

9 may be useful or required in the prescribing process, can 

10 accordingly be incorporated in systems according to the 

11 invention. Processing demands on the user's device can be 

12 minimized by confining the device's capabilities to 

13 recognition of the signatures of only tnose users authorized 

14 to use that particular device. 
15 

16 Adding higher performance hardware to support the processing 

17 needs of handwriting recognition may be impossible with 

18 available technology if a preferred lightweight, compact 

19 form factor is to be retained for the user's device. An aim 

20 of the invention is to provide a qualified prescribing 

21 professional with a valuable tool that imposes no 

22 significant burdens of weight or volume on the user, that 

23 demands little of their time and yet can respond rapidly, 

24 delivering valuable drug and patient information to _the user 

25 from remotely located, disparate sources. In other words, 

26 an aim of the invention is to provide an intelligent, 
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1 knowledgeable computerized prescription pad. 
2 

3 This aim could be compromised by adoption of handwriting 

4 recognition technology at the date of this application. 

5 Similar problems apply to voice recognition as a significant 

6 data input medium. Either or both handwriting and voice 

7 recognition may be valuable enhancements of future 

8 embodiments of the inventive systems especially if future 

9 technology makes these capabilities available on smaller 

10 user devices. In particular, limited voice recognition may 

11 be valuable as a user identifier for password access or as 

12 an authorizing signature. 
13 

14 Security 

15 Security may be provided by password protection operating 

16 hierarchically on one or more levels, to provide varying 

17 degrees of access according to the user's level of 

18 authorization, as desired. Additional password or numeric 

19 code control may protect sensitive system-accessed 

20 information, for example, patient records, or parts thereof, 

21 or physician-user data, including personal lists and 

22 prescribing profiles. 
23 

24 Patient record access codes can, in selected instances, be 

25 patient provided, or granted by intelligent security control 

26 cards, having been furnished to the patient by a system 
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1 administrator, or agent, prior to the physician encounter. 

2 Physician or other user access to a patient's record, or to 

3 sensitive details thereof, can thereby be restricted to a 

4 need-to-know basis. Access by third parties to physician- 

5 related data can be similarly protected. 
6 

7 Provision for override of such security features should be 

8 available, for example for an emergency room doctor, and is 

9 allowed on a special case exception basis, is auditable, and 
10 traceable to the overriding user. 

11 

12 Password-controlled access to many computer networks is 

13 often workstation dependent with each workstation using a 

14 unique password to access the network. Although user 

15 passwords may also be employed, these are often workstation- 

16 dependent, for example, being incorporated in the 

17 workstation's login scripts. In contrast thereto the 

18 present invention prefers that user access to the host 

19 computer facility be device-independent so that a given user 

20 can access the system via any of numerous devices, provided 

21 they have the right password or passwords. By this means, 

22 users are not dependent upon a single device that may be 

23 lost or misplaced. 
24 

25 A still more preferred feature is to have user passwords 

26 which link each user with an individual profile or style 
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1 sheet on the host computer facility representing the user's 

- 2 patterns of preferences so that the user-customization 

3 features of the system, which will be described more fully 

4 hereinafter, are readily available to the user independently 

5 of the particular interface device that happens to be 

6 employed for accessing the system. 
7 

8 These and other device-independent features can permit the 

9 prescription management system to be fully operative without 

10 committing useful data to storage on the user device. This 

11 is a valuable security feature. In the event of theft or 

12 attempts at unauthorized use, even by skilled third parties, 

13 a user device will oe worthless as a means to access 

14 sensrtrve dans on the system or to use the system illegally. 
15 

16 Optionally, lost or stolen devices can be deactivated by the 

17 application or by system software, after user notification, 

18 by erasing or otherwise rendering device-resident 

19 application procedures inoperable, without loss of device- 

20 resident data. Use of a virtual patient record, as 

21 described herein, which need not be stored locally, is a 

22 valuable safeguard against unauthorized access of 

23 confidential data on lost, stolen or "borrowed" user 

24 devices. 
25 

26 Host computer facility 
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1 Currently contemplated preferred embodiments further control 

2 the processing and storage demands placed on the user's 

3 device by intelligently delegating data-processing and 

4 storage activities to a linked remote, host computer 

5 facility, as referenced above, to the extent warranted by 

6 the capabilities of the user device. Thus, for example, a 

7 comprehensive drug database may be stored and maintained on 

8 such a host computer facility with selected data, for a 

9 particular drug list or an individual drug's formulation 

10 characteristics, being forwarded to the user's device on an 

11 as-needed basis, then being eliminated from the user device 

12 when no longer required. Other activities may 

13 advantageously be performed locally on the device, such as 

14 dynamic assembly of records from elements retrieved across 

15 the network from remote storage, and storage of the user's 

16 personal or most frequently referenced data and data lists, 

17 where the device T s capabilities permit. 
18 

19 Where the user device is more powerful than present-day 

20 PDA's, for example a present-day desktop computer or perhaps 

21 the PDA's of the future, more processing and data storage 

22 functions can be retained at the user device rather than 

23 delegated to the network. Although permanent (disk, 

24 diskette or flash memory) storage may have uses, security 

25 concerns can be better managed on the network than on the 

26 user device, so that it is preferred that minimal data be 
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permanently stored on the user device. Accordingly physical 
storage resources of limited user devices are preferably 
allocated to RAM rather than permanent storage. 

Advantageously, a user profile can also be stored on the 
host computer facility so that if the user device is lost, 
broken or stolen, a new device can be automatically 
reconfigured across the network linking the user to the host 
facility, so that the application behaves the same. 

Preferably such a host computer facility also provides 
customized services to each user device, performing "user- 
adaptive" functions for that aevice, as described herein, to 
adapt it to its authorized user or user's prescribing 
behavior and improve the level of assistance provided to the 
user. Employing such off-loading techniques, permanent 
storage capabilities of the device can be minimized in favor 
of faster RAM storage capabilities. 

The screens are designed to be non-intimidating to computer- 
inexperienced professionals and to present familiar 
information and terminology to them while avoiding 
specialist computer jargon. Individually, they are easy-to- 
use for novices yet rapid enough for experienced users. 
Collectively, they provide an appealing system interface 
which can flexibly integrate into a physician's personal 
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1 work flow. 
'2 

3 In addition, the screens are laid out in the manner of 

4 appealing logical forms that echo familiar data formats 

5 encountered by a physician in their day-to-day work. An 

6 important objective is to make the screens self explanatory 

7 within the professional's normal terms of reference so as to 

8 avoid any need for access to help, although of course, HELP 

9 buttons can be provided if desired and extensive help 

10 documentation can also be provided. System utilities such 

11 as indexing, setup and purging are either concealed from the 

12 user or removed for execution on a remote host computer 

13 facility. Data integrity and availability responsioiiities 

14 are also delegated to the host computer facility, or its 

15 remote data suppliers. Thus data saving, archival, backup 

16 and data-replication functions are host facility 

17 responsibilities, not concerns of the user, 
18 

19 The system is designed to require a minimum of actual text 

20 or data entry. So far as possible, item entry is effected 

21 by selection from lists of items, for example by 

22 highlighting an item, then clicking a mouse, or more 

23 preferably penning, to activate an item. 
24 

25 The prescription management system is made as user-friendly 

26 to physicians as possible, for example, by using familiar 
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1 professional terminology and abbreviations. Thus terms such 

2 as "Patient" or "Pt", "Drug" or "Rx", "Condition" or "Dx" 

3 and "Treatment" or "Tx" are used rather than confusing 

4 generalities such as "subject" and "item" that often appear 

5 in generic software. The Prescription Management System 

6 shown in this embodiment of the invention has been designed 

7 for use with small portable personal computers, especially 

8 hand held devices known as personal digital assistants. 

9 Those skilled in the art will understand that the system can 

10 readily be used on or adapted to other hardware platforms, 

11 for example, a physician's desk top computer and can be 

12 expressed in different software interfaces from that shown. 
13 

14 Referring now to Figure 1 the system entry screen 

15 illustrated has a user-customizable button bar 10 which has 

16 been set with a conventional Quit button 12 and a Help 

17 button 14, along with a Mail button 16 for accessing an 

18 electronic mail ("E-Mail") system, a Prescribing button 18 

19 for accessing the prescription management system embodiment 

20 of the invention, an Encounter button 20 for accessing a 

21 patient encounter management system (not further described 

22 herein) . Ans Svc button 22 accesses an answering service 

23 screen (not shown) , which as a convenience function can be 

24 dynamically linked via the host computer facility to "log 

25 incoming calls for the user. The answering service is 

26 preferably intelligent and prioritizes, by flagging or 
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1 displaying, patient- or treatment-related calls, for example 

'2 those from a pharmacy, while screening out' or de-prioritizes 

3 less relevant calls. 
4 

5 Historv-cocniitive drug and condition listing 

6 A Doctor's Lists button 24 accesses a more or less complex 

7 display of patient condition and therapeutic drug lists. 

8 Preferably, the drug and condition lists are linked together 

9 to associate a drug with one or more conditions for which it 

10 might be prescribed and, in most cases to provide the 

11 physician user with a conveniently displayed, concise 

12 selection of drugs for treating any particular condition. 

13 In a preferred feature of this invention, the system has a 

14 user-adaptive character and adapts itself to the user's 

15 habits and prescribing patterns so as to service the user 

16 more efficiently. To this end, the drug lists or the 

17 condition lists, or both, are system-modified with use to 

18 reflect the prescribing frequency of particular drugs or the 

19 frequency of occurrence of particular conditions. Thus, 

20 more frequently prescribed drugs or more frequently 

21 encountered conditions can be presented to the user 

22 physician in a more prominent manner or more immediate 

23 manner than ones found by the system to be historically less 

24 common in the particular user prescribing environment. In 

25 this way the system becomes more valuable with use as the 

26 drug and condition lists develop into personalized lists 
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1 featuring the user's preferences. 

'2 

3 With such cognitive features the inventive system is 

4 effectively cognizant of ongoing prescribing activity. It 

5 comes to know its user's environment and preferences, can 

6 adapt itself to any number of specialist situations, and 

7 can, if suitably equipped, subtly prompt the user, online 

8 with original, relevant, but elusive information derived 

9 from the user's computer-memorialized practice experience. 

10 For example the system may prompt the user that the last 

11 time Drug X was prescribed for Condition Y, Patient Q 

12 reported adverse reaction Z. Where the host computer 

13 facility documents a catalog of known adverse reactions to 

14 system-listed drugs, a system enhancement can report new 

15 adverse reactions to the user or centrally, to the host 

15 computer facility, by tracking logged patient conditions and 

17 relating them, where appropriate, to a previous 

18 prescription. In similar manner the system may log drug- 

19 drug interactions, which interactions can also be associated 

20 with a target condition or conditions. Many other valuable 

21 retrospective statistical studies and analyses are made 

22 possible by deployment of the invention, as will be apparent 

23 to those skilled in the art. While such studies are 

24 potentially of immense public value if widely implemented, 

25 careful controls will be required to avoid reporting 

26 unrelated conditions as adverse drug reactions. 
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With time, as it adopts appropriate specialist prescribing 

patterns, the user-adaptive prescription management system 

of the invention can be just as relevant and useful to, for 

example, a specialist in tropical medicine as it is to a 

pediatrician. This desirable result can be achieved without 

encumbering either specialist with the needs of the other. 

Those skilled in the art will appreciate that the 
invention's cognitive, user-adaptive features employ 
significant programming routines and procedures and are 
quite different from common, user-responsive software 
defaults which merely offer defaults pre-set by the user or 
simply show the last used item, file or the iiKe as a 
default . 

If desired, the user's prescription management system can 
have built-in, online, statistical reporting functions 
enabling a physician user to review their, or others, 
historical experience with a particular drug or condition 
and providing online historical review of any other 
activities or data entrusted to the system. 

Of scientific note is that the system is privy to and 
operates at the confluence of three powerful emergent data 
streams: encyclopedic data on therapeutic agents intended to 
moderate particular conditions or patient problems; data on 
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1 individual prescriber activity using skill and judgment to 

'2 diagnose conditions or problems and make prescribing 

3 decisions selecting and applying therapeutic agents to 

4 diminish diagnosed conditions/ and patient history data 

5 recording not only prescribing decisions but also the 

6 results of those decisions (see the description of Figure 

7 12, below) . Thus, the system captures not only prescribing 

8 activity but also the prescriber T s intent, the problem or 

9 condition targeted by the prescriber in specifying a 

10 particular drug, and can track the success of that intent. 

11 The linkage of treatment with condition treated captures the 

12 reason why the doctor took the prescribing action that was 

13 taken. This intent may, and can legally, be different from 

14 approved FDA therapeutic indications for a drug. 
15 

16 Of commercial note is that the foregoing data may be 

17 aggregated for multiple users, for example by the host 

18 computing facility, for market research purposes. Also, an 

19 individual user's prescribing patterns may be reviewed by 

20 the user or by others. For example, drug benefits 

21 companies, can review the user's prescribing patterns for 

22 formulary compliance and respond by encouraging better 

23 compliance, where appropriate. Release of such data to 

24 third parties can be controlled to safeguard the privacy of 

25 the prescriber, or other health care provider, by 

26 prescriber-determined data access protocols specifying who, 
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1 or what organization, department or group, may access what 

2 data, when they may access it and what they can do with it. 

3 For example, one physician may permit academic use for 

4 research studies and prohibit commercial use while another 

5 may permit either. 
6 

7 As will be described in more detail subsequently, a range of 

8 optional features, for example the answering service and e- 

9 mail features mentioned above, or other communications 

10 features, can be made available from button bar 10 providing 

11 the user with user-configurable means to customize the 

12 system to their personal needs and tastes. 
13 

14 Intelligent drug- selection procedure 

15 Skeptical prescribers are encouraged to adopt the 

16 prescription management system of the invention, by its 

17 ability to bring to the point-of-care, in readily utilizable 

18 form, a battery of relevant drug-specification information 

19 and important patient-related information, much of which is 

20 not readily accessible at the point-of-care by conventional 

21 means. 
22 

23 Preferred embodiments of the invention achieve this 

24 desirable result by providing an intelligent drug-selection 

25 procedure which is supported by transparent connectivity to 

26 multiple remote proprietary information systems at the point 
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of care, enabling a physician to draw upon the following 
categories of data: 

i) physician-user prescribing-f requency data; 
ii) patient drug formulary information as to a drug's 
status with a patient's drug benefits provider; 
iii) drug dosage characteristics, for example, form, 
size, route of administration, amount, frequency 
and the like; 
iv) drug-specific treatment information as to 

condition-related efficacy, and preferably as to 
contraindications and adverse reactions; 
v) relevant patient history information as to current 
and previous prescriptions, and preferably also, 
pursuant to the teaching of the present invention, 
problem-history information; and 
vi) laboratory and other diagnostic test information 
related to the patient's indications, to dosing, 
to therapeutic choices or to specific drug 
selections . 



Preferably, this data is brought to the point-of-care by 
relying upon retrieval from remote source databases at 
remote facilities responsible for capturing original update 
data, and not by relying upon redundant non-source data 
requiring constant synchronization with source data to 
remain current. 
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1 Diagnostic tests 

2 Items i)-v) above, will be described in considerable detail 

3 hereinafter* With regard to diagnostic tests and 

4 procedures, for example radiology, the invention 

5 contemplates electronically bringing relevant information to 

6 the point of care to assist health care providers make 

7 informed decisions. Such diagnostic information may 

8 comprise recommendations for clarifying a tentative 

9 diagnosis, or choice of diagnoses, or may comprise 

10 diagnostic results that can be used to make more informed 

11 therapy decisions and, in particular, to make better 

12 therapeutic drug selections. Body system function tests, 

13 for example renal or liver function tests are clearly 

14 valuable to a drug selection process, since renal and liver 

15 condition are important in determining dosages of some 

16 medications. Other therapy-relevant diagnostic 

17 determinations can usefully be presented at the point of 

18 care, by means of the present invention, for example, drug- 

19 level determinations can enhance dosing decisions. 
20 

21 Patient encounter program 

22 A useful, prescription management system-compatible patient 

23 encounter program can begin, with a patient selection screen 

24 such as that of Figure 2. The patient selection screen of 

25 Figure' 2 can be activated by any one of multiple programs 

26 which may, for example, be initiated via the system entry 
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1 screen of Figure 1, but could be independent, free-standing 

2 programs or any other program for which the ability to 

3 create, update and modify a patient-specific record or a 

4 patient history is valuable, 
5 

6 Preferred embodiments of software procedures (or programs) 

7 associated with the novel patient record selection procedure 

8 illustrated in Figure 2 can access multiple remote databases 

9 to retrieve patient records, for example, by using the host 

10 computer facility, and can also post new patient records, 

11 and updates, created locally by the physician-user, io the 

12 multiple remote databases in real time, or in batch mode. 
13 

14 Patient record source data 

15 Source data for a typical patient record may be distributed 

16 across multiple, geographically dispersed, electronically 

17 incompatible, remote databases maintained for example by 

18 drug benefit companies, insurers, laboratories, medical 

19 facilities, diagnostic testing facilities and health 

20 maintenance organizations, including government agencies 

21 (MEDICAID, MEDICARE, etc) and health care providers 

22 themselves, that have serviced the patient in the past, 

23 Known automated patient record systems either ignore such 

24 remote data and work only with data created at the 

25 maintaining facility or vertically integrated health care 

26 organization, or create and maintain duplicates of the 
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1 remote data. 
2 

3 Still more preferred embodiments of the invention provide 

4 substantial savings of resources, time and effort by using 

5 only source data for patient records, minimizing creation of 

6 multiple redundant local databases that require constant 

7 synchronization with remote sources if they are to remain 

8 accurate and up to date. 
9 

10 The invention also provides novel data-retrieval network 

11 systems to retrieve relevant patient data elements from 

12 multiple remote heterogenous primary source databases. 

13 Preferably, every time a host computer facility receives a 

14 call from a user device for a patient history or patient 

15 record, relevant data elements, for that record, or a record 

16 component (e.g. the most recent six-month or twelve-month 

17 portion) , are retrieved from remote source databases, 

18 dynamically assembled, or integrated, into a virtual patient 

19 record, as described above, and delivered to the user device 

20 as an integral system data set. Alternatively, record 

21 assembly, which does not require undue hardware resources, 

22 can be performed on board the user device. 
23 

24 The record is viewed and may be printed out by the user, 

25 with patient authorization, but does not need to be 

26 permanently stored. 



-42- 

1 The host computer facility responsible for dynamic assembly 

'2 of the virtual record logs the time, date and calling user 

3 to provide an audit trail of access to the patient's record, 

4 but does not commit the record to permanent storage. After 

5 use, the virtual patient record disappears, although it can 

6 be reconstructed archivally. 
7 

8 If the record is required again, it is assembled anew, 

9 thereby incorporating any updates that may have occurred in 

10 the interim, for example changes in drug benefit status, 

11 insurance coverage or the like, newly generated laboratory, 

12 radiology or other diagnostic results, or other, e.g. 

13 emergency, prescriptions dispensed. Tne acz of assembling a 

14 record externally of its sources immediately dates the 

15 record: it is cut off from any updates, and therefore liable 

16 to become incomplete, obsolete or dated. Virtual patient 

17 record assembly, as described herein, avoids this problem 

18 making local storage of patient records unnecessary. 
19 

20 Transactions are archived by the host system to provide a 

21 complete transaction history, so that past activity can be 

22 reconstructed. Such a data-reconstruction capability to 

23 provide clear hind vision of the patient's record at any 

24 given time is an important medicolegal capability. That 

25 historical version is preferably reconstructed from a 

26 transaction log and assembly of timed and dated record 
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1 elements, or segments, in a manner not unlike that used by 

2 version control software. 
3 

4 Creating a virtual patient record permits optimal data 

5 currency and accuracy and, by avoiding unnecessary redundant 

6 copies of patient data minimizes liability for misuse or 

7 unauthorized access. Patient confidentiality can be 

8 maximized and is verifiable by the system-generated audit 

9 trail. 
10 

11 Preferably for individual record elements to be admitted to 

12 the system, they are required to be at least dated and 

13 preferably also to be timed at source, such riming and 

14 dating relating to whatever event created the record. In 

15 addition to its value as an integral record characteristic, 

16 chronological data is useful for retrospective archival 

17 reconstruction of a record as it existed (in its elements) 

18 at any given point in time. This can be achieved by 

19 retrieving record elements, as described above, using a 

20 suitable date filter and if appropriate, a time filter, to 

21 include only those (or selected ones of those) record 

22 elements that existed at the desired given point in time. 
23 

24 Such an archival retrospective record reconstruction - 

25 capability is a highly desirable adjunct to the virtual 

26 patient record described herein permitting full creation and 
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1 examination of any desired historical records, such as may 

2 be required for review or legal purposes. 
3 

4 Using the above-described method of dynamic retrieval from 

5 remote databases across a data-retrieval, record-integrating 

6 network, source database proprietors can remain wardens of 

7 the only copy of that data and obtain patient authorization 

8 to be the sole repository of that data. Laboratories can 

9 keep laboratory records; insurance companies can keep 

10 insurance records; hospitals can keep hospital records; and 

11 health maintenance organizations can keep their own records; 

12 without ever having to release copies of these records into 

13 external electronic storage by third parties, with the 

14 security hazards attendant upon such releases. Any 

15 electronic release made externally using the data access 

16 control features described herein can be assured of always 

17 being authorized by whatever entity, be they patient, 

18 physician or organization, that has proprietary rights in 

19 the data. 
20 

21 Figure 2: Patient selection screen 

22 Upon selecting Prescribing button 18 by clicking or pen 

23 contact, a patient selection screen, for example as shown in 

24 Figure 2, is displayed as a preliminary to prescription 

25 management functions. Referring to the patient selection 

26 screen of Figure 2, the name, age, gender, and social 
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1 security numbers of patients who have authorized the user 

"2 physician to treat them, or to access the system on their 

3 behalf, are listed under respective column header buttons, 

4 namely, Name button 2 6, Age button 28, Gender button 30 and 

5 Social Security # button 32. 
6 

7 Lists can be scanned, or text entries made in a blank search 

8 box 34 at the top of the screen, using string or full name 

9 searches to locate the desired patient or to review the 

10 patient list. Column headers 26-32 can be clicked or 

11 touched to sort the patient list on any of those fields and 

12 activate search box 34. Search box 34 is linked to the sort 

13 fields so that, for example, if the listing is sorted by 

14 social security number then alphabetical entry attempts are 

15 rejected from search box 34 and numeric entries are used as 

16 social security number locators. The characters can be 

17 keyed or system provided from pop-up screens, or voice or 

18 handwriting recognition may be employed. 
19 

20 New Pt button 36 activates a new patient entry bar, while 

21 the Ok button 39 accepts a highlighted patient selection and 

22 advances to the prescription management screen of Figure 3. 

23 Cancel button 38 returns to .the system entry screen of 

24 Figure 1. 
25 

26 If desired, preliminary selection of groups of patients can 
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1 be made by providing various patient lists, for example 

'2 "Today's Patients", "In-Patients", "Out-Patients", "Private 

3 Patients" and the like. Such patient lists are preferably 

4 system-maintained, on an ongoing basis, using the latest 

5 data available to the system and preferably enable the user 

6 to select a convenient group of patients that has a high 

7 probability of including the next patient or patients to be 

8 encountered, thereby speeding access and retrieval of a 

9 desired patient record. Where the user typically encounters 

10 patients in groups, for example one group in an out-patient 

11 clinic and another group in an in-patient clinic, such 

12 grouping of patient records into lists also facilitates 

13 organization by a host computer facility of display data 

14 into small batches that can more rapidly be communicated via 

15 limited capacity copper wires and modems and are of a size 

16 that can conveniently be held in RAM on a small, portable 

17 user device. 
18 

19 Patient Data Security 

20 Critical to public confidence in the prescription management 

21 system of the invention are issues of security, since the 

22 system requires access to personal records. Many people 

23 will fear unauthorized access to or use of their personal 

24 information. Preferably, the invention provides careful 

25 controls to alleviate such fears and to prevent unauthorized 

26 access to a patient r s data or to their physician's 
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1 prescribing profiles. 

"2 

3 Preferably also, the system, or an associated support 

4 network, provides data access controls such that the only 

5 accesses that can occur are those that have been authorized 

6 or preauthorized, at a point of care or elsewhere, in 

7 accordance with security profiles on the network established 

8 on behalf of data-proprietor entities such as patients, 

9 physicians or organizations. It is further preferred that 

10 the entity's security profile, or filter, details what data 

11 can be accessed, when it may be accessed, where it may be 

12 accessed and by whom it may be accessed. 
13 

14 Various suitable data access control measures will be known 

15 to those skilled in the art and considerable security can be 

16 obtained by using more or less complex identifiers for 

17 patients or for physician-users of the system or for both. 
18 

19 Patient records should use a standard identifier to be 

20 clearly and distinctly identified with a confidence level 

21 appropriate to the expected patient population in the 

22 lifetime of the system so that the records of patients with 

23 similar or identical names are not confused. If desired, a 

24 coded alphanumeric patient identifier (not shown) may be 

25 used. Alternatively, or in addition, other unique patient 

26 identifiers such as social security numbers may be used 
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1 alone or as secondary references in conjunction with patient 

2 names and the like. 
3 

4 More relevant to security is proper identification of a user 

5 to whom patient data is released or from whom new data is 

6 received by the host computer facility. While numeric or 

7 alphanumeric user identification codes provide some level of 

8 security, higher levels are provided by using graphic, 

9 photographic or fingerprint recognition to identify a system 
10 user. 

11 

12 More preferred embodiments of the invention can ensure a 

13 still higher level of confidentiality oy automatically 

14 maintaining a complete audit trail of access to patient 

15 data. Preferably the audit trail details, for every access, 

16 who or what organization accessed the record, what part of 

17 the record was accessed, when it was accessed (both date and 

18 time) and what was the purpose of viewing the record. Thus, 

19 associated with every patient record is a timed and dated 

20 log of every physician user, organization or health care 

21 professional accessing that record. If desired, the log can 

22 be reported, or made available to a patient, on request, for 

23 example through online access (with careful security 

24 controls) , via print or fax, and so on. 
25 

26 Patient-directed control of the flow of their own data, a 
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1 novel concept in medical or health care information systems, 

'2 can be achieved by centrally inputting at the, or a, host 

3 computer facility patient-generated record-access 

4 specifications to determine which users, or user 

5 organizations or departments (for example clinics) , can 

6 access what data during what period and what uses can be 

7 made of the data. Clearly, such specifications must not 

8 deleteriously restrict physicians in the execution of their 

9 professional missions. Such record-access specifications or 

10 profiles could be maintained at a remote database rather 

11 than the host computer facility. Thus, access to their 

12 records is controlled by patients and individuals and 

13 organizations can be given patient-defined, selective access 

14 or access based on a need to know, or a patient may block 

15 access to all data flow, if they wish. In emergencies, 

16 physicians may be able to override a patient security block, 

17 but such events are recorded so that any abuse can be 

18 monitored and action can be taken to discourage abusers. 
19 

20 MD-Related Data Security 

21 Many similar data security considerations apply to 

22 prescriber-related data. Used comprehensively, as it is 

23 intended to be, the system is privy to full particulars of a 

24 physician user's professional prescribing behavior, _day in, 

25 day out, potentially throughout their career. System 

26 resources may be used to compile any desired historical 
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1 record of a user's prescribing activities. Patient- 

"2 confidentiality aspects of this data have been addressed 

3 above and can be satisfactorily managed by controlling 

4 access to patient-related data in accordance with a 

5 patient's previously, or currently expressed wishes, as 

6 described herein. In addressing physician-oriented 

7 prescribing issues, the historical record may be rendered 

8 patient-anonymous by stripping the data of recognizable 

9 patient identifiers, or aggregating the data. The resultant 

10 historical prescribing data can communicate significant 

11 information about the prescriber, is personal and 

12 proprietary to the prescriber. 
13. 

14 Pursuant to this invention, the prescriber T s rights in their 

15 historical prescribing data are protectable in a manner 

16 similar to the protection affordable to patients, by 

17 providing prescriber-determined access control 

18 specifications detailing permissible levels of third-party 

19 access to prescriber data. Such prescriber data access 

20 control specifications can be stored in individual files on 

21 the network and can comprise as to who or what organization, 

22 or type of organization may access what data, for what 

23 purpose and for what period of time such access right may be 

24 effective. Clearly, multiple levels of access control may 

25 be described to any desired degree of complexity. User 

26 preferences may include user authorization for data access 
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1 by various third parties for example health maintenance 

'2 organizations (HMO's), hospitals, government agencies, 

3 managed care organizations and so on. 
4 

5 A particular group to whom a prescriber may wish to yield 

6 access rights comprises collective bargaining associations, 

7 for example independent practitioner associations, preferred 

8 provider organizations and physician hospital organizations, 

9 Preferably, all accesses to a prescriber f s data are system 

10 stamped with a date, time and accessor ID, to create an 

11 audit trail of such accesses, similar to the audit trail 

12 left by accesses to patient data. 
13 

14 System-determined access control can be invoked, whenever a 

15 prescriber data access request is received, by referencing 

16 the prescriber T s access control file and permitting or 

17 denying access in accordance with the file's specifications. 
18 

19 Prescription creation screen 39 

20 Referring to Figure 3, prescription creation screen 39 has a 

21 full array of user-activatable buttons enabling a physician 

22 to draw on powerful resources within the prescription 

23 management system and supporting it in the host computer 

24 facility and associated data-retrieval network, as will 

25 shortly be described. Near the top of screen 39 is a 

26 patient features bar 40 below which a prescription features 
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1 bar 42 coordinates all features necessary to review current 

'2 therapy and order changes in treatment, or order new 

3 treatment, for the selected patient. A prescription history 

4 zone 43 extends across the middle of the screen, the lower 

5 screen portion contains a prescribing zone 44, and a screen 

6 title 45 appears at the top of the screen. 
7 

8 Patient features bar 40 comprises a Select Patient button 

9 46, a selected patient indicator 48, in this case Mary 

10 Harrington, a patient Problems button 50 and a patient 

11 Allergies button 52. Beneath Problems button 50 are 

12 displayed Mary Harrington's currently active problems 51 or 

13 conditions, shown here as pharyngitis and bronchitis. 

14 Beneath Allergies button 52 are displayed Mary Harrington's 

15 known allergies. Pressing or otherwise activating Problems 

16 button 50 or Allergies button 52, opens a window or screen 

17 listing problems or allergies from which a physician, or 

18 other professional user, can select new problems or 

19 allergies to add to Mary Harrington's record, or delete ones 

20 that are no longer active. Optionally, system-provided 

21 problem or allergy libraries may be organized into multiple 

22 lists with button 50 or 52, respectively, opening a list 

23 selection box as a preliminary to displaying a selected 

24 problem or allergy list. 
25 

26 Problems or conditions 51 and allergies 53 are here 
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1 displayed as a helpful notation for the prescriber and do 

2 not become prescription elements as a result of being 

3 selected for display in this part of the screen. However, 

4 selections made here are functional in that selected 

5 problems 51 (conditions) will become defaults or preferred 

6 choices in a subsequent condition specification procedure 

7 and the system will review any drugs prescribed for 

8 relevance to allergies 53. 
9 

10 Prescription features bar 42 comprises an Rx History button 

11 54, an Rx Options button 56, an Updating indicator 58, an Rx 

12 Info button 60 and a Renew Rx button 62. 
13 

14 Prescription history zone 43 displays those historical 

15 prescription details that may be relevant to a current 

16 prescription and has a Condition field 64, a Drug field 66, 

17 a Size field 68 a Dosing field 70, a generic flag 72, an 

18 Expires field 74 and a Mine field 76, in which the various 

19 characteristics of patient Mary Harrington's previous 

20 prescriptions are listed. 
21 

22 Prescribing zone 44 comprises three active buttons, New Rx 

23 button 78, Send Rx button 80 and Close button 82, below 

24 which extends a prescribing header bar 84 which contains 

25 field identifiers for data entry of a full complement of 

26 prescription details. Available prescription detail fields 
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1 comprise a Condition field 8 6, a Drug field 88, a Generic 

2 field 90, a Form field 92, a Size field 94, a Route field 

3 96, an Amt (Amount) field 98, a Refill field 100, a Dosing 

4 field 102 and an Expires field 104. 
5 

6 Multiple lines of the selected patient's prescription 

7 history are listed in patient history zone 43 in the middle 

8 of the screen for convenient review by the physician-user, 

9 and possible renewal, with scrolling or paging of extensive 

10 histories. Depending upon the patient's previous 

11 whereabouts and service providers, individual lines may come 

12 from multiple remote sources. Such histories are preferably 

13 compiled by the host computer facility in response to a call 

14 from the user device (see the description of Figure 16) . 
15 

16 Prescribing zone 44, lower down prescription creation screen 

17 39, allows a physician user to select and prescribe drugs 

18 and dosages, for the selected patient, in this case Mary 

19 Harrington, and to transmit the created prescription 

20 externally across a data network to other interested and 

21 authorized parties for prescription fulfillment, patient 

22 record updating and the like. 
23 

24 Select Patient button 46 returns to the patient selection 

25 screen of Figure 2 for selecting a different patient from 

26 one or more lists. Preferably, Select Patient button 46 



-55- 

1 draws up a "Today's Patients" list or whichever patient list 

"2 the user last selected from, or a default, user-selected 

3 patient list, and provides the options of selecting a new 

4 patient from alternative patient lists. 
5 

6 Problems button 50 brings up a patient problem history 

7 information screen such as that shown in Figure 12 (to be 

8 described) in which a historical record of the patient 1 s 

9 individual symptoms and diagnoses is listed and to which new 

10 problem reports can be posted. To maintain data integrity, 

11 and as a legal safeguard, historical information is not 

12 editable but may be supplemented, for example by reporting 

13 the subsequent status of a problem as (still) active or 

14 inactive. Preferably, any such additions to the record are 

15 stamped with the identity of the reporting physician, 

16 providing valuable elements of a treatment decision-making 

17 audit trail. 
18 

19 The patient 1 s drug-related allergies, or drug reactions, are 

20 brought up in possibly editable form (screen not shown) by 

21 activating an Allergies button 48 and may be automatically 

22 system updated, if desired by adding newly reported drug 

23 reactions and allergies. Desired personal or drug records 

24 relevant to possible allergies of this patient may be 

25 summoned from the host computer facility, which may in turn 

26 call on the remote database data-retrieval network for 
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1 records or record elements. 

2 

3 

4 Rx History button 54, scrolls, drops down, or otherwise 

5 accesses any additional patient history lines beyond what 

6 will fit in prescription history zone 43 and may introduce 

7 vertical or horizontal scroll bars, or both, into zone 43, 

8 enabling the user to display any desired section of a 

9 patient's prescription history in zone 43 with the top line 

10 of the history highlighted. Any desired prior prescription 

11 line displayed in zone 43, can be highlighted by clicking or 

12 pressing on it. 
13 

14 A highlighted prior prescription can be automatically 

15 renewed by clicking or pushing an Renew Rx button 62. 

16 Typically, prescription creation screen 39 opens with the 

17 most recent prescription highlighted for possible renewal. 

18 Activating Renew Rx button 62 posts a highlighted prior 

19 prescription into prescribing zone 44 for automatic renewal, 

20 after editing, if desired. Renewal of any prior 

21 prescription can thus be effected in as few, as two user 

22 steps by pressing Renew Rx 62 to post a highlighted 

23 previous prescription to prescribing zone 4 4 and a single 

24 further action to complete a prescription from there: If 

25 desired option buttons such as Renew and Send Last 

26 Prescription or Renew All Active Prescriptions can be added. 
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1 Pressing header buttons Condition 64, Drug 66, or Expires 

2 74 causes the drug history display to be sorted by the 

3 selected header enabling the prescription history to be 

4 evaluated according to a particular parameter. This feature 

5 is of particular value for patients with long and complex 

6 treatment histories, 
7 

8 An important novel feature of the inventive prescription 

9 management system is the ability to associate a specific 

10 patient condition with each drug prescribed. By capturing 

11 detailed information on every prescription the system 

12 automatically builds a novel patient medical record having 

13 new uses in evaluating individual patient treatment and in 

14 enabling powerful new, multi-center outcome studies for 

15 evaluating therapies in various populations of parients. 
16 

17 By deploying the inventive system regionally, nationally or 

18 in some other population area, and employing the preferred 

19 methods for retrieving patient data from remote sources, as 

20 described herein, a complete patient record of all activity 

21 within a region can be built. Preferably this is a virtual 

22 patient record dynamically assembled only from original 

23 source data, which, as described above, is maintained in 

24 component form at multiple distributed source databases, is 

25 retrieved therefrom across a data-retrieval network from 

26 which the source databases can be accessed, and is compiled 
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1 or assembled into a single virtual or transient record that 

2 appears to the user as an integral system data resource. 
3 

4 Outcome studies , prescription cost savings and drug alerts 

5 Patient histories generated by the inventive system can show 

6 not only the drugs prescribed, but also the conditions for 

7 which they were prescribed, allergies, demographics, 

8 insurance coverage, treating health care providers, and so 

9 on. Known medical management systems do not provide 

10 listings associating each prescribed drug with a patient 

11 condition or problem, as reported to, or diagnosed by their 

12 physician. 
13 

14 Careful review of a patient ! s record for relationships 

15 between amelioration of problems and prescription of 

16 particular drugs can provide important information about the 

17 efficacy of a drug for a particular problem in a given 

18 patient. Review of a physician's prescribing record, 

19 detailing the various drugs selected to treat the different 

20 conditions exhibited by the patients encountered in the 

21 physician's daily practice, can reveal valuable information 

22 about the physician T s prescribing practices and the degree 

23 to which they follow formulary guidelines. 
24 

25 This information is clearly of value to the individual 

26 physician and can, if desired, be enhanced by including in 
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1 the problem record a condition severity rating, enabling 

2 declines (or increases) in severity to be reported. The 

3 resultant patient prescription history, replete with dated 

4 information as to patient problems, what drugs were 

5 prescribed to treat those problems, what forms, routes of 

6 administration and dosages were used and, by implication 

7 from the timing and nature of subsequent problems, what the 

8 outcome of that prescription was, provides a very attractive 

9 treatment evaluation tool to a physician, and a powerful 

10 inducement to any professionally conscientious physician to 

11 use the prescription management system of the invention. 
12 

13 Implementing the invention on a wider scale, valuable new 

14 outcome studies and clinical trials are easily, or even 

15 automatically, performed. One of many problems in 

16 successfully implementing the herein described prescription 

17 management system on a large scale is one of funding the 

18 system. Medical cost structures, with their reimbursement 

19 systems leave little scope for expenditure on aids to 

20 overall practice improvements which may have to be squeezed 

21 out of tight overhead budgets. Accordingly, significant 

22 cost to the physician user, or user's medical facility will 

23 be a major deterrent to system adoption. Preferably the 

24 system is provided to prescribing users on a low-cost or no- 

25 cost basis with funding from outside sources. 
26 
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1 Implementation of the invention is expected dramatically to 

2 reduce the overall cost of prescriptions and this saving has 

3 been estimated to be from 20 to 40 percent of total 

4 prescription costs. Savings will accrue initially to the 

5 drug benefit management companies who reimburse the direct 

6 costs of most prescriptions, but can be expected eventually 

7 to be passed to corporations and consumers by way of lower 

8 drug benefit rates. Such savings realized on a national 

9 scale would amount to many billions of dollars and provide 

10 an avenue of reimbursement for system proprietors. In the 

11 early 1990 ! s, the cost of prescription drug benefits is one 

12 of the fastest rising components of all health care costs. 
13 

14 Outcome studies produced by the system may have substantial 

15 value to various parties, and their sale can support system 

16 costs, as may formulary compliance savings. For example, 

17 drug efficacy data is of value to pharmaceutical companies, 

18 as is early warning data from reliable specialists regarding 

19 adverse reactions. Subject to confidentiality and other 

20 relevant controls, such data can be automatically compiled 

21 and readily supplied by system management, requiring only 

22 approval, not active participation by involved physician 

23 prescribers. Equally, the system may facilitate clinical 

24 trials by identifying health care providers or prescribers 

25 who would be likely participants in trials, based upon their 

26 having frequently diagnosed relevant conditions, or 
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1 specified relevant drugs, as shown by their historical 

'2 prescribing profiles, or relevant patient histories. 

3 Suitable patient pools can be identified similarly. 
4 

5 Organizations participating in outcome studies, for example 

6 health maintenance organizations, insurance companies, 

7 hospitals, physician alliances and the like, and may pool 

8 their data but may not wish to reveal certain proprietary 

9 data. By employing data access control methods for 

10 accessing such organizational data, such as the methods 

11 described in detail herein for controlling access to 

12 patient's rights, the system of this invention can enable 

13 organizations to control what data they release. 
14 

15 To implement such clinical trials, additional information 

16 required for collection can be obtained by flagging selected 

17 prescribers' profiles to trigger additional on-screen 

18 routines so that whenever a trial-related drug or condition 

19 is selected by the prescriber, they will be asked to supply 

20 necessary additional information. For example, whenever a 

21 prescriber participates in a trial relating to treatments 

22 for gastritis, the system can request information as to 

23 whether certain tests were performed, and what were the 

24 results of those tests. Thus, the test drug might be 

25 appropriate for, or be in trials relating to, gastritis 

26 testing positive to if. pylori, whereas a different drug 
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1 would be indicated for H. pylori-negative gastritis. 
2 

3 The system can also provide, preferably from source 

4 databases, complete prescription drug disclosure 

5 requirements as set forth by the FDA, including full 

6 cautionary information, for example as is now set forth in 

7 the Physicians' Desk Reference (Medical Economics) and 

8 Physician's GenRx (Denniston Publishing) knowledge of which 

9 by the prescriber may be necessary to avoid malpractice 

10 liability, and dissemination of which may limit a drug 

11 manufacturer's liability. Efficient promulgation of drug 

12 disclosure information to system users is tantamount to 

13 publication, yet can be more current than any printed 

14 document, and may be accepted as an alternative to hard copy 

15 publication or supersede it. 
16 

17 In addition, the system provides a valuable means for 

18 government agencies and others to communicate important 

19 messages, such as drug warnings and alerts, quickly and 

20 directly to physician users. Electronic mail accessed via 

21 Mail button 16 can be used for this purpose, and may include 

22 priority flags triggering screen alerts, but a much more 

23 powerful route for communicating warnings relating to 

24 particular drugs is to associate the alert with system 

25 information on the drug so that when a user calls up the 

26 drug in question, they receive the warning or alert, or 



-63- 



1 other special message. 
'2 

3 In the extreme case of withdrawal of a drug from the market, 

4 that fact can immediately be communicated to system users. 

5 Thus a drug can be withdrawn from the market the same day by 

6 making a system entry preventing completion of a 

7 prescription for the withdrawn drug. Alternatively, a 

8 warning can be posted directly to the prescription. Current 

9 users of the medication can be identified from prescription 

10 history records, referencing not only drugs prescribed, but 

11 also prescription expiration dates. Both the patient and 

12 their doctor can be notified immediately. In this case, 

13 electronic mail is a preferred route for notifying the 

14 physician. 
15 

16 Relative cost-to-benefit data can also readily be prepared 

17 in outcome studies when individual drug costs are factored 

18 into the data, and such costrbenefit data can, in some 

19 circumstances have very substantial dollar value to drug 

20 benefits management companies whose objectives are to 

21 maximize the quality of care while minimizing the cost of 

22 that care. 
23 

24 Pharmaceutical and managed care companies can gain marketing 

25 benefits from use of the system to introduce new drugs or 

26 new uses of old drugs to physicians, in a relevant manner, 
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1 at a moment of peak interest. 
2 

3 Other benefits can be derived from outcome studies using the 

4 novel drug-prescribed and condition-treated data records 

5 provided by the prescription management system of the 

6 invention. For example , the appearance of a new patient 

7 problem may be insignificant when associated with prior 

8 prescription of a particular drug for one patient, but may 

9 . gain significance when repeated for a number of patients. 
10 

11 Optional system enhancements may enable post-introduction 

12 market surveillance of new drugs to be conducted for adverse 

13 outcomes to the treatment of a specified condition or 

14 conditions. For example the system may monitor patients 

15 reporting new problems after having been prescribed the new 

16 drug in question, refer such new problems to the physician 

17 user to qualify them for medical relevance and then 

18 statistically compare a collection of similar reports with 

19 data on a pool of similarly treated patients for 

20 significance. 
21 

22 Continuous post-market-introduction monitoring of a drug in 

23 relation to the treatment of conditions is possible, and an 

24 end-to-end solution to the problem of managing unanticipated 

25 problems arising with new drugs can be provided: the system 

26 provides a vehicle data collecting relevant data; parameters 
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1 and a means for analysis of that data; and a means for 

2 disseminating alerts and advisories regarding newly 

3 discovered problems. The same vehicle is used for all three 

4 steps. 
5 

6 With such a system enhancement, one specialist pioneering a 

7 new drug for a particular condition may provide an early 

8 warning of adverse reactions not identified in clinical 

9 trials in a manner not heretofore obtainable, because of the 
10 difficulty of coordinating prescription and diagnostic data. 
11 

12 Quickly and conveniently presented at the point of care, as 

13 an integral part of the prescribing process, in the manner 

14 achieved by the system of the invention, rhis information 

15 can be of immense value to a physician when treating a 

16 patient, widening the physicians' choices beyond their own 

17 field of knowledge (by suggesting new drug information) and 

18 helping the physicians optimize the prescribing process. 
19 

20 Another advantage of the invention is that each physician 

21 user inherently and easily supplies critical enabling data 

22 for outcome studies as part of the prescribing process. No 

23 extra effort is required by .the physician to make the data 

24 available for studies. One potential difficulty in .making 

25 such studies is the existence of legal barriers to 

26 aggregating patient data into studies without specific 
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1 patient permission. While this might be obtained on a 

2 piecemeal basis or by the prescribing physician, a much 

3 better solution is provided by centrally maintaining patient 

4 directed patient-record-access specifications, as described 

5 above. The system can then include only those records of 

6 patients agreeable to becoming study participants in such 

7 outcome studies. 
8 

9 The historical drug-prescribed and condition-treated records 

10 obtainable by using the invention can provide a basis for 

11 condition-based treatment guidelines developed by drug 

12 formularies. This novel data provides a new vehicle for 

13 outcome research for managed care, leading to new approaches 

14 to cost-effective prescription treatments. 
15 

16 Compilation of an extensive or national database of 

17 (patient-anonymous) records providing a statistical 

18 historical listing of drugs prescribed versus associated 

19 conditions for which they were prescribed would be in the 

20 public interest and of considerable value, so long as 

21 patient-confidentiality were maintained. Widespread 

22 adoption of the present invention can help achieve this 

23 desirable goal. It is relevant to note that FDA regulations 

24 only permit a drug to be promoted for approved, specific 

25 therapeutic purposes but physicians are professionally free 

26 to prescribe an approved drug for any condition for which 
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1 they believe the drug to be effective or useful so that, 

2 failing specific point-of-care diagnostic information, no 

3 assumptions can be made as to the treatment objectives of 

4 any particular prescription. Accordingly, prior to the 

5 present invention, statistical prescribing data have 

6 generally lacked knowledge of why a physician prescribed a 

7 particular drug, and such data is, in most cases, not useful 

8 for outcome studies and cannot be related back to other 

9 patient-specific variables present in the patient ! s medical 
10 record. 

11 

12 Prescription history record 

13 Referring to the prescription history zone 43 of tne Eigure 

14 3 screen, under the Condition field 64 is listed a condition 

15 reported as active when the drug was prescribed. Drug field 

16 66 may be a generic name or a brand name. The Size field 68 

17 is the dosage size. Dosing field 70 shows the dosing 

18 frequency. The "G" flag 72 is for generic and is a simple 

19 yes/no indicator. An Expires field 74 displays an 

20 expiration date system calculated from the prescription 

21 quantity (not shown) , the size and the dosing rate and 

22 indicates the day on which the prescription will run out. 
23 

24 The last column, Mine field 76, is a yes/no toggle flag 

25 indicating whether the prescribing physician was the current 

26 system-designated physician user ("Y" = my prescription) or 
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1 some other physician ("N"). Another prescribing physician's 

*2 details and other data relevant to a previous prescription 

3 can be obtained by pressing Rx Info button 60, or double- 

4 pressing or -clicking on the appropriate prescription 

5 history line, to draw down a prescription information 

6 screen, for example, as shown in Figure 12, Additional 

7 ' available options, if any, can be accessed through the Rx 

8 Options button 56. 
9 

10 Update button 58 can be a simple blinking indicator alerting 

11 the user that their device is communicating with the host 

12 computer facility and actively processing a local update. 

13 To indicate additional time taken accessing remote 

14 databases, the message can change to "Remote Retrieval", if 

15 desired. Additionally, Update button 58 can activate 

16 various update options, selectable from a menu, if desired. 

17 For example, Update button 58 may offer a selection of 

18 different sources from which to update the patient ! s 

19 prescription history. While a preferred objective of the 

20 invention is that the prescription management system obtain 

21 a comprehensive, nationwide update of any previous 

22 prescribing activity regarding this selected patient, 

23 considerations of system speed, system development or 

24 marketing considerations may make it desirable to of-fer 

25 patient prescription histories drawn from all prescribing 

26 activity in a more limited geographical region, for example, 
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1 local or regional updates local network updates or 

"2 capability to update from the physician's institutional or 

3 office practice information systems. 
4 

5 New prescriptions 

6 Activating the New Rx button 78 highlights the first 

7 available blank line in the lower portion of the 

8 prescription management screen for creation of a new 

9 prescription by a physician-user. During the prescription 

10 creation process, the user receives intelligent decision 

11 support from the system of the invention. Preferably, the 

12 system proffers the prescribing physician comprehensive 

13 relevant prescribing data to enable creation of a new 

14 prescription intelligently, in an informed, manner with 

15 routine look-up functions being fully automated so that 

16 professional time spent on routine chores is minimized or 

17 eliminated. To this end, data entries available via both 

18 Condition button 8 6 and Drug button 88 are selectable from 

19 extensive lists, as will be described hereinafter. 
20 

21 As described above, the system provides the user through 

22 their interface device and a linked host computer facility, 

23 transparently connectivity to multiple remote proprietary 

24 databases for retrieving necessary data such as drug and 

25 condition lists. 
26 
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1 Pressing (or clicking on) highlighted fields beneath the 

2 headers in prescribing header bar 84, in most cases, 

3 activates pull-down menus, or data entry scrolls. Generic 

4 field 90 is merely a toggled flag while Expires field 104 is 

5 a system-calculated field. Although provision can be made 

6 for a physician to make original entries, the preferred 

7 embodiment provides a comprehensive selection of system- 

8 generated drug prescribing data from which the user may make 

9 selections . 
10 

11 If the user knows the drug they wish to prescribe, the drug 

12 name may be keyed in or, preferably selected by highlighting 

13 and clicking from one or more intelligently maintained lists 

14 presented in drop-down menus to post it to the respective 

15 highlighted field under Drug header 88. Alternatively, the 

16 user can select a condition from a condition list and make a 

17 drug selection appropriate to that condition from a drug 

18 selection screen such as those shown in Figures 4 through 11 

19 as will shortly be described in more detail. 
20 

21 Generic flag 90 is a simple yes/no indicator which is linked 

22 to each drug selection to approve generic drug substitution 

23 for brand name drugs by the pharmacist, if such substitution 

24 is permitted by state regulation. 
25 

26 Prescription quantification 
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1 The Form, Size, Route and Amounts headers 92-98 are linked 

2 to the drug selected and bring system resources to bear to 

3 enable a prescriber rapidly to quantify the prescription 

4 with appropriate dosages that can be filled at a pharmacy, 

5 without undue difficulty. Activating any one of the fields 

6 under headers 92-98 drops down a menu, which menus together 

7 offer a selection of all known formulations of the drug 

8 selected, as provided by the manufacturer, using 

9 comprehensive drug inventory data accessed via the host 

10 computer facility or its supporting data-retrieval networks, 
11 

12 The entry for Form field 92 may be selected from choices 

13 such as capsule, caplet, tablet, and liquid. That for Size 

14 field 94 might be a selection of 50 mg, 100 mg, and 200 mg 

15 and the Route field 96 selections might be Tf PO" for per 

16 oral, by mouth, "PR" per rectum, "IV" for intravenous, and 

17 so on. The displays are related and intelligently selected 

18 ro display relevant options. Thus, for example, if "PO" is 

19 selected as the route of administration, only PO dosage 

20 forms are displayed. On the other hand, if PO oral forms 

21 are selected, "PO" appears as the route of administration. 
22 

23 The Amt field 98 is the amount or quantity of drug to be 

24 dispensed in the prescription, for example 30, 50 or 100 

25 capsules or 50, 55, or 100 ml of liquid. Refill field 100 

2 6 shows the number of times refilling is permitted and Dosing 
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field 102 has two columns, one being a numeric designation 
of a number of tablets, caplets or liquid dosages to be 
taken at any one time and the other being an alpha 
indication of the dosing frequency such as QD for daily. 

In an optional, modified embodiment of the invention (not 
shown) , the system can calculate or suggest effective 
dosages for a selected drug, or a narrow range of effective 
dosages, according to dosage-relevant patient 
characteristics, for example, height, weight, age, sex, 
pregnancy and the like, taking into account the physical 
formulations in which the drug is known to be available. 
While these characteristics might be entered or selected 
from lists during the prescription quantification procedure, 
greater power is obtained by including them on the patient's 
record and having the system reference these characteristics 
each time a new drug is prescribed for that patient and make 
dosage recommendations according to the known behavior of 
the selected drug as it applies to the current patient. 



Referring to the embodiment illustrated in the drawings, 
Expires field 104 can be system-calculated field from the 
entries in Amount field 98 and Dosing field 102, to. indicate 
the day on which the last dose will be taken. 
Alternatively, the physician-user can select, or enter, an 
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1 expiration date in Expires field 104 for example to coincide 

'2 with a desired duration of treatment, or next visit, the 

3 system can back-calculate refills or the amount dispensed. 
4 

5 Back-calculating prescription quantifiers is useful to 

6 coordinate multiple prescriptions to expire on the same day, 

7 for the patient's convenience and to reduce potential errors 

8 or abuses. Another valuable application of an expiration- 

9 controlled prescription is to benefit plan managers, 

10 enabling the physician, where appropriate, readily to 

11 coordinate prescription amounts to preferred schedules and 

12 programs of drug benefit plan managers, for example a 

13 ninety-day plan. Such preferred schedules can be system- 

14 offered or defaulted, if desired. 
15 

16 Alternatively, if desired, means can be provided for the 

17 physician themselves to write or key in the appropriate 

18 dosage entries for a selected drug. 
19 

20 In this preferred embodiment of prescription management 

21 system according to the invention, the Drug and Condition 

22 fields 88 and 86 are linked together to express the 

23 therapeutic objective of the user's prescribing decisions, 

24 or the prescribing intent of the prescription, as will be 

25 described in more detail with reference to Figures 4 through 

26 11. 
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1 As stated above, a preferred objective of the invention is 

2 to minimize need for keyed dara entry, to minimize 

3 information look-up, or preferably to avoid all need for 

4 keying, by providing a comprehensive system interfacing with 

5 the user through easily operated data entry devices such as 

6 employed in pen-based computer devices. To achieve this 

7 end, the prescription management screen of Figure 3, is 

8 preferably supported by comprehensive, fully adequate, up- 

9 to-date databases of drug information that, in a 

10 particularly preferred embodiment of the invention, provide 

11 a physician user with substantially all available relevant 

12 prescribing information on drugs, especially on those drugs 

13 they write most frequently, which may be favored with 

14 preferential device storage on the user's interface device, 

15 for rapid retrieval. Relevant prescribing information on 

16 other drugs, written less frequently, or not at all by that 

17 user is available on the network. 
18 

19 Prescription fulfillment 

20 When drug specification is completed to the physician's 

21 satisfaction, Send Rx button 80 is pressed to output the 

22 newly created electronic prescription in any desired form 

23 such as to print, to local or remote storage or to remote 

24 file transfer as an electronic prescription. The electronic 

25 prescription can be transmitted across a network for 

26 fulfillment by any specified pharmacy, for example, the 
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1 patient's preferred pharmacy or a pharmacy preferred by the 

2 patient's drug benefit company for the particular patient's 

3 locality. Preferred routing options can be provided for the 

4 patient or the drug benefit plan, or both, and the system 

5 can default to appropriate options for the patient's benefit 

6 plan. Routing may be more or less complex and may for 

7 example split say a one-month prescription to provide a 

8 bridge prescription giving the patient an immediate one- or 

9 two-week supply from a local pharmacy, and sending the 

10 balance of the prescription for fulfillment by a lower cost 

11 mail order house. If desired, a Bridge Rx button (not 

12 shown) may be added to prescription creation screen 39 to 

13 perform such a prescription-splitting function. 
14 

15 Patient compliance and prescription drug abuse 

16 Ensuring th^t a patient complies with the terms of a 

17 prescribed treatment, neither neglecting nor overindulging 

18 in a prescribed drug therapy, is a serious problem in health 

19 care management. It is difficult to ensure that out- 

20 patients actually ingest the prescribed amounts of 

21 • medication at the prescribed intervals. Many mistakes and 

22 abuses occur. The problem is exacerbated when a patient is 

23 prescribed a confusing multiplicity of drugs that may have 

24 to be ingested in different amounts at different times of 

25 the day. The present invention enables, and includes, 

26 unique solutions to this problem that greatly facilitate a 
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1 patient's ability to comply with a simple or complex regimen 

2 of dosages, without costly skilled supervision. In 

3 addition, many types of intentional abuse can be monitored 

4 and possibly prevented* 

5 One approach to enhancing patient compliance, according to 

6 the invention, employs a novel dose-scheduling drug package 

7 that is readily adaptable to accommodating and scheduling 

8 single or multiple prescription dosages to help a patient 

9 take the right dose of the right drug at the right time, and 
10 will be described in detail hereinbelow. 

11 

12 Another approach is, to some extent, inherent in features of 

13 the prescription management system described herein. wnere 

14 multiple physicians accessed by a patient utilize the system 

15 described herein, with common online access to, and assembly 

16 of, a patient's prescription history record whereby that 

17 record provides a current record of new prescriptions, then 

18 a common abuse can be controlled wherein a patient presents 

19 a problem or condition to more than one physician to obtain 

20 multiple prescriptions with a view to indulging in abusive 

21 ingestion or illicit resale. This problem is especially 

22 prevalent with analgesics. Where a physician, or perhaps 

23 pharmacist, if the patient's prescription history is 

24 available to the pharmacist, sees a similar current _ prior 

25 prescription has been issued, they can refuse to duplicate 

26 it. 
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1 patient's ability to comply with a simple or complex regimen 

2 of dosages, without costly skilled supervision. In 

3 addition, many types of intentional abuse can be monitored 

4 and possibly prevented. 

5 One approach to enhancing patient compliance, according to 

6 the invention, employs a novel dose-scheduling drug package 

7 that is readily adaptable to accommodating and scheduling 

8 single or multiple prescription dosages to help a patient 

9 take the right dose of the right drug at the right time, and 
10 will be described in detail hereinbelow. 

11 

12 Another approach is, to some extent, inherent in features of 

13 the prescription management system described herein. where 

14 multiple physicians accessed by a patient utilize the system 

15 described herein, with common online access to, and assembly 

16 of, a patient's prescription history record whereby that 

17 record provides a current record of new prescriptions, then 

18 a common abuse can be controlled wherein a patient presents 

19 a problem or condition to more than one physician to obtain 

20 multiple prescriptions with a view to indulging in abusive 

21 ingestion or illicit resale. This problem is especially 

22 prevalent with analgesics. Where a physician, or perhaps 

23 pharmacist, if the patient's prescription history is 

24 available to the pharmacist, sees a similar current prior 

25 prescription has been issued, they can refuse to duplicate 

26 it. 



-77- 

1 Clearly, regulatory authorities wishing to control such 

2 abuses can further that goal by encouraging widespread, or 

3 universal, deployment of the prescription management system 

4 of the invention. Where the system also provides, for 

5 example in the patient T s history record, notification from a 

6 pharmacy, or from a drug benefit plan linked to the 

7 pharmacy, of fulfillment of a prescription, and that 

8 information is available to the prescriber, for example from 

9 the patients 1 history record, another common abuse wherein a 

10 patient pleads loss of a prescription to obtain a duplicate, 

11 can also be prevented. 
12 

13 Bringing fulfillment information from the pharmacy to the 

14 point of care via the patient's record or other convenient 

15 reporting medium, with or without the intermediary of a drug 

16 benefit company linked as a remote source database, can 

17 provide not only a valuable prescription abuse monitoring 

18 parameter but can also be used to enhance compliance with 

19 the prescribed treatment, especially if coupled with an 

20 alerting system. 
21 

2.2 For example, the system may alert a prescriber that the 

23 intended expiration date of a critical prescription has 

24 passed without the prescription having been filled. . The 

25 prescriber thus becomes aware that the patient has gone off 

26 the medication and can take steps to contact the patient and 
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1 alert them to the dangers or problems that may arise. 

'2 Alternatively, routine alerts can be passed to 

3 administrative personnel associated with the prescribing 

4 health care provider, notifying them of any unfilled 

5 prescription after a prespecified period of say two weeks or 

6 a month, or prescription expiration, or a shorter period for 

7 more critical medications. 
8 

9 Scheduled dosage drug pack 

10 A particular benefit the system provides when a patient has 

11 multiple simultaneous prescriptions is an ability to print 

12 out a dosing schedule or better still, to generate a 

13 scheduled dosage multi-drug package from -che electronic 

14 prescription, for example as shown in Figure 15. Because 

15 the system knows dosage, dosage frequency and the duration 

16 of all prescriptions, it can report our whan pills should be 

17 taken at different times of the day to comply with the 

18 requirements of multiple medications. The information used 

19 for such a- further report can drive the dispensing of the 

20 drugs of a multi-drug prescription into a novel package 

21 which has multiple labeled or coded compartments for each of 

22 a number of dosing intervals. 
23 

24 Figure 15 shows a scheduled dosage drug pack 182 configured 

25 as a daily pack with the day of the week prominent and the 

26 date, patient and doctor identified. Across pack 182 run 
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1 three multi-compartment drug bays 184 each of which can 

2 accommodate up to four different solid drug formulations 

3 184, pills, capsules, tablets, caplets, or the like and is 

4 sealed by a tear strip having an opening tab 186. Each bay 

5 is clearly labeled with a time of day at which the dosage in 

6 each bay 184 should be taken. Vertical zones 188 are 

7 dedicated to an individual drug and comprise a header with a 

8 drug name and special instructions (take with water, after 

S food, and so on) and a compartment in each bay 184 for each 

10 dosage time. To demonstrate the flexibility and dose- 

11 organizing power of this novel, pack-based system a first 

12 drug is shown schematically in lefthand zone 188 with 

13 tnrice-daiiy dosing, a second in iefu central zone 188 wiuh 

14 ' uwice-daily dosing and a third in right central zone 188 

15 with once-a-day dosing. Righthand zone 188 is not used, but 

16 could be occupied by a fourth drug, the individual dosages 

17 of which are loaded into those individual compartments of 

18 Righthand zone 188 that correspond with desired dosage times 

19 or intervals. 
20 

21 Clearly, modified drug packs 182 embodying the principles of 

22 that shown in Figure 15 could be configured for more (or 

23 fewer) doses or drugs or for different calendar periods, for 

24 example weekly or monthly packs rather than daily. Nor is 

25 the card configuration essential, for example, a multi-drug 

26 container could be in strip or roll or book form, or metal 



-80- 

1 foil sheets, with tear or press-out compartments. Dosing 

"2 errors are common with patients with multiple prescriptions, 

3 especially the elderly. There can for example be difficulty 

4 " in knowing whether a dose has been taken or not. Drug pack 

5 182 solves these problems in a simple inexpensive manner 

6 that is prescription controlled to organize multiple doses 

7 correctly and can be easily followed by most patients. 

8 Individual sealing of doses is hygienic and child- or 

9 overdose-resistant. Daily or weekly cards could be 

10 connected together by hinges to make compact concertina or 

11 book-like packs supplying a week or a month's prescribed 

12 drug requirements. 
13 

14 Variations on the theme of a scheduled dosage package will 

15 be apparent to those skilled in the art. If desired, the 

16 package could be standardized as to the number of dosage 

17 compartments, providing for example, a compartment for every 

18 -hour, with those compartments lying between desired dosage 

19 times being obviously blank or never filled. A valuable 

20 feature of such packaging, which could be embodied in a 

21 single prescription package, is that by giving the 

22 physician-prescriber some physical control over the 

23 circumstances that exist when a patient is supplied with 

24 drug therapy for remote administration, the prescriber gains 

25 the freedom to adopt time-related dosage variations during 

26 the course of therapy, without confusing the patient. In a 
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1 simple example, scheduled packaging might provide one pill 

'2 in the morning, one at lunch rime, and two at night, in an 

3 attempt to maintain blood drug levels through the night. 
4 

5 Other regimens could provide higher initial dosages to build 

6 up blood drug levels, followed by lower maintenance dosages. 

7 In any such case, the patient simply takes, or is 

8 administered, at any given time, whatever dosage or dosages 

9 have been packaged into the bay 184 that is appropriately 

10 identified by patient, time and date. More subtle or more 

11 complex regimens will be apparent to those skilled in the 

12 art, for example one drug might be discontinued, and 

13 possibly resumed after a suitable interval, while another 

14 continues. Another useful technique to be able to 

15 administer via the dosage-scheduling package described 

16 herein is to taper down one drug while beginning to 

17 administer another, to provide a graduated switchover. 

18 Changing anticonvulsant therapies from one drug to another 

19 is an example of where this technique may be useful. 
20 

21 Prescriber-controlled dosage scheduling can be included in 

22 the system via an additional window or screen, offering the 

23 prescriber selection of the relevant variables, such as 

24 time-related dosages, with defaults or preferred selections 

25 for what can be system-determined as the most probable or 

26 most beneficial choices for the patient being treated, or 
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i accord with the patient T s f ormuiary T s preferences or with 

"2 the particular prescriber's preferences, pursuant to the 

3 principles described herein. Specific tapering or starting 

4 protocols can easily be implemented for outpatients 

5 decreasing the requirement for costly skilled supervision. 
6 

7 Dosing Indicator Device 

8 For more needy patients , the time- and date-scheduled drug 

9 packaging described herein can be rendered electronically or 

10 electro-optically readable, for example with bar-coding or 

11 by using transparent compartments, to cooperate with a novel 

12 dosing indicator device that a patient could take with them 

13 to their home or on their travels. Such a novel dosing 

14 indicator device, as contemplated herein, includes a time- 

15 and-date clock and is designed to receive at least one 

16 scheduled dosage package, as described herein, and to 

17 inspect that package to determine what drug pills, capsules 

18 or the like have been removed. In the event that a pill or 

19 the like is detected in any bay stamped with a date and time 

20 prior to the date and time clocked by the device, an audible 

21 or visual or remote alert, or a combined alert, is 

22 triggered. Inspection sensing is preferably electro-optical 

23 and targets individual compartments with a light beam that 

24 is reflected or diffused by an individual pill or associated 

25 light-modulating tag, or by a bar code stamp or label which 

26 is required to be removed with each dosage of any drug. The 
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1 device can include a movable scanner that advances in 

'2 relation to a package from one bay 184 to the next, scanning 

3 relevant compartments in the bay, as time passes, or it can 

4 comprise an array of photoelectric sensors registering with 

5 individual compartments of the package, which are 

6 electronically controlled and read in turn, as time passes. 

7 Equivalent sensing systems will be apparent to those skilled 

8 in rhe art. 
9 

10 A preferred embodiment of dosing indicator device 

11 accommodates, within an aesthetically pleasing housing, a 

12 multi-bay scheduled dosage package, a time-and-date clock, a 

13 time-related sensor to detect the presence of a drug dosage 

14 in the bays one or more alerting systems, associated 

15 electronics which may include a microprocessor, and a power 

16 supply, for example, a battery, ac connector or remote 

17 drawdown source, or the like. 
18 

19 Such a dosing indicator device can be embodied as a motor- 

20 driven single- or multi-drug dosage dispenser which, for 

21 example, can house a tape, or strip-like and preferably 

22 rolled, scheduled dosage package, having a time line along 

23 the roll, and advances individual bays 18 4 containing one or 

24 more dosages for a given dosage time, and presents 3* single 

25 bay 184 (containing one or more dosages) for external 

26 delivery and removal (for example by tearing) by the 
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1 patient, or patient's aid, in timed relationship to the 

"2 dosage time (a half hour before, perhaps) and triggers one 

3 or more alerts if the bay 184 is not removed (a half hour 

4 after, perhaps) . 
5 

6 Preferably, each bay is accompanied by written information 

7 as to the patient, time and date, each drug, and any 

8 relevant dosing instructions. The individual compartments 

9 of such a removable bay cannot readily be sensed for the 

10 presence of individual pills. Clearly a sensor is required 

11 for the presence of an externally exposed bay. The system 

12 assumes that the pills in a removed bay will be ingested, 

13 but this assumption may be wrong on occasion. More rigorous 

14 patient compliance may be exaczed by including in, or in 

15 association with the device, a receptacle for an emptied bay 

16 184 and triggering alert means if such emptied bay is not 

17 received within a specified time interval. Emptied bays can 

18 be retained within the receptacle. To deter deceit of the 

19 receptacle it can read a time and date stamp, or other 

20 unique identifier on bay 184. 
21 

22 A multipatient version of the drug dosage dispenser 

23 described herein can also b.e provided for inpatient use in 

24 medical or health care facilities, especially hospitals and 

25 clinics. Such a multipatient version could comprise a 

26 central dispensing station, located for example at a nurse's 
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1 station. The dispensing station can have multiple ports, 

"2 preferably identified with bed locations and bed-occupants T 

3 names, whereby scheduled drug dosages for each bed-occupant 

4 patient are dispensed at scheduled dosage intervals, if 

5 desired with appropriate alerts or indicators . Nursing or 

6 other staff can readily remove and administer the correct 

7 drug dosages for multiple patients, possibly on a single 

8 round, or at specific times of the day. 
9 

10 Drug contraindications 

11 A further valuable feature of the novel prescription 

12 management system described herein is an ability to review a 

13 completed prescription for contraindications, or relative 

14 contraindications, such as patient allergies to the 

15 prescribed drug and such as possible drug-to-drug 

16 interactions with other drugs the patient has previously 

17 been prescribed. Contraindications may be clear-cut, for 

18 example, penicillin must not be selected for penicillin- 

19 allergic patients, whereas relative contraindications are 

20 less decisive and may be overridden by the prescriber in 

21 appropriate circumstances, for example an NSAID (non- 
22 steroidal anti-inflammatory drug) may be a preferred choice, 

23 in the prescriber T s judgment for a patient with peptic ulcer 

24 disease, in spite of the attendant risk of ?? 
25 

26 The system can also screen or review for other possible 
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1 unintended adverse outcomes to the prescribed therapy, or 

"2 for special precautions regarding a prescribed drug's use. 
3 

4 Preferably, the system alerts the physician-user at the 

5 point-of-care if they prescribe an offending agent, and 

6 provides an alert and an opportunity to amend the 

7 prescription before dispatching it for fulfillment. 

8 Processing to screen for interactions may occur on the 

9 user's point-of-care device or on the host computer facility 

10 or remote computer system, or may be delegated elsewhere by 

11 the host computer facility, and reported back to the 

12 physician, online as an integral function of the 

13 prescription process. Alternatively, interaction screening 

14 may be run on pharmacy-related systems, and notification of 

15 problems can be sent immediately to the user's point-of-care 

16 device using e-mail or using procedures within the 

17 prescription management application of the invention. 
18 

19 An allergies review can be conducted by checking system- 

20 stored known allergies of patient Mary Harrington against 

21 known pharmacokinetics and pharmacodynamics of the newly 

22 prescribed drug, entered in prescribing zone 44, for any of 

23 those allergies. Mary Harrington's allergy information is 

24 preferably an adjunct to her patient record and is „• 

25 downloaded to the user device from host computer facility 

26 when Mary Harrington is selected from the patient selection 
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1 screen of Figure 2. Drug allergenic proclivities are also 

' 2 downloaded from one or another remote database employing the 

3 host computer facility, under supervision of the inventive 

4 prescription management system, but preferably at a later 

5 point in the procedure, such as when a particular drug is 

6 selected for posting to prescribing zone 44. 
7 

8 Alternatively, the requisite information can be downloaded 

9 when the allergy review is conducted. Such allergy 

10 screening can alternatively be effected when a new drug is 

11 posted to Drug field 88. Either way, a positive system 

12 finding, indicating a risk of allergic reaction to the newly 

13 selected drug can activate a visual indicator or warning, 

14 for example, Allergies button 52 may blink and, if desired, 

15 an audible warning may sound alerting the physician to 

16 reconsider their selection. Alternatively, or additionally, 

17 an alert screen can tell the physician of an allergy if an 

18 -attempt is made to prescribe an offending drug. Such alerts 

19 can be used to notify the physician of drug interactions, 

20 treatment warnings or can alert them to non-compliance with 

21 formulary recommendations, for example to the use of an 

22 unnecessarily expensive drug, and may be accompanied by 

23 suggestions for more appropriate alternative therapies. 
24 

25 Equivalent procedures can alert to possible drug 

26 interactions and contraindications, referring to the 
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1 patient's prescription history for possible active or 

"2 recently expired prescriptions that may interact with a 

3 newly prescribed drug, and for other patient data relevant 

4 to the drug's behavior in that patient. Alternatively, the 

5 such a review for possible undesired aspects of the drug's 

6 performance on the patient is made upon activating Send Rx 

7 button 80. 
8 

9 Electronic prescription transmission 

10 Activation of Send Rx button 80 can provide a drop-down menu 

11 of choices including "Send this prescription" and "Add 

12 prescriptions prior to sending in a batch". 
13 

14 A preferred embodiment of the invention includes a 

15 capability whereby a completed prescription is transmitted 

16 across one or more data networks for fulfillment and record 

17 updating in a wired or more conveniently, for mobile 

18 professionals, a wireless broadcast. Preferably, where new 

19 information is generated in the prescription creation 

20 process, relevant remote source databases (which may be 

21 proprietary) are updated with appropriate components of the 

22 new information and such updates are effected with proper 

23 controls to ensure data integrity, confidentiality and 

24 authenticity. Using the system as described herein^- all 

25 transactions generate an audit trail and are authorized or 

26 preauthorized by the patient. 
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1 Because of the currently substantial cost of air time, batch 

"2 transmission is highly desirable. Accordingly, system 

3 defaults encourage the physician to elect batch transmission 

4 of multiple prescriptions for an individual patient, 

5 although in keeping with the principle of not imposing 

6 constraints on a physician, the system does not mandate such 

7 batch transmission. Executing a "Send Prescription" 

8 function outputs the prescription for fulfillment in any 

9 desired form, posts the completed new prescription to the 

10 prescription History zone 43 in the center of the screen, 

11 and outputs the new prescription from the user's station to 

12 update a control system or remote database, as desired. 

13 Prescriptions can be electronically transmitted to a 

14 pharmacy or pharmacy-management system for fulfillment, or 

15 printed on paper for paper-based fulfillment by hand 

16 delivery or fax. 
17 

18 The inventive prescription management system embodiment 

19 disclosed herein is designed flexibly to facilitate a 

20 physician's prescribing activities, to place helpful 

21 information at their fingertips and reduce manual look-up 

22 chores, while avoiding any authoritarian direction, mandate 

23 or constraint upon a physician's professional activities or 

24 judgement. Thus, while the system may attempt to provide 

25 intelligent options and exhaustive selection lists, options 

26 such as "other" are always available to permit the 
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1 prescriber complete freedom of choice, whether or not their 

2 choice is known to system-available databases. 
3 

4 Optional system enhancements provide for enrichment of 

5 external communications, for example prescriptions and e- 

6 mail with what may be termed "electronic ink" messages 

7 generated at the user device. "Electronic ink" refers to 

8 notes or messages appended to external communications, or 

9 transactions in the form of free text or voice annotations 

10 for non-structured instructions, and the like. Voice 

11 annotation is particularly convenient, as well as possibly 

12 constituting unique user-identification and some currently 

13 available low form factor user devices incorporate a 

14 microphone, facilitating voice annotation. 
15 

16 Toward the end of prescribing flexibility, to avoid being 

17 second-guessed by physician users, and to command their 

18 respect and loyalty, the system should have access to, and 

19 provide to its users fully comprehensive drug and patient 

20 information so far as this is available. Comprehensive, 

21 accurate and complete drug and patient information are 

22 equally important for effective prescribing. It follows 

23 that the drug and patient information source databases from 

24 which the prescription management system draws, must -be 

25 maintained up to date, by appropriate network services. 
26 
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1 It is the normal, challenging nature of highly qualified 

2 professionals that those with the latest news, such as new 

3 drug releases and approvals, will want immediately to test 

4 the system for currency with the news. 
5 

6 The unique source-oriented information retrieval and 

7 updating system described herein provides preferred means 

8 for supporting the prescription management system of this 

9 invention with an adequate infra-structure of data-retrieval 

10 networks supplying a comprehensive array of up-to-date 

11 prescribing information and patient-related data to the 

12 point-of-care. Other suitable information data retrieval 

13 and updating systems will be apparent to those skilled in 

14 the art and can be linked to the system of the present 

15 invention to provide allergy and interaction alerts, 

16 formulary changes, new drug approvals, and to lock out or 

17 warn against, the prescribing of inappropriate or recalled 

18 drugs. 
19 

20 Drug and condition selection 

21 Novel drug selection methods pursuant to the invention will 

22 now be described with reference to Figures 4 to 11. The 

23 condition list selection screen shown in Figure 4 appears 

24 upon activation of Condition field 8 6 in the prescription 

25 management screen of Figure 3, to enable a prescriber to 

26 approach selection of a treatment drug by first specifying a 
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1 diagnosed condition. Alternatively,, a drug may be directly 

2 specified by drug name by activating Drug field 88, as will 

3 be described in connection with Figure 9, after which the 

4 prescriber selects a condition to specify the purpose of the 

5 therapy. Such condition or drug selection screens can be 

6 opened by similar condition or drug buttons in any other 

7 relevant screen or application, for instance in a patient 

8 encounter screen where the drug selection routines now to be 

9 described with reference to Figures 4 to 11 can be used to 

10 assist a physician to select or review treatment objectives 

11 in a computer-assisted patient encounter. 
12 

13 Condition list selection 

14 The condition list-selection screen of Figure 4, provides a 

15 preliminary selection of a suitable condition list from 

16 which a physician user can work to select a drug. As shown, 

17 the screen comprises a Select Condition List title 110 and a 

18 Condition List display header 112 beneath which the names of 

19 Condition Lists 114 are grouped in a left-hand column. A 

20 right-hand column beneath header 112 displays the conditions 

21 116 of whichever condition list 114 is highlighted, or 

22 otherwise selected. In this case the user's personal 

23 condition list 114 has been highlighted and may be seen to 

24 comprise a short list of commonly occurring problems that, 

25 for example, a general practitioner might encounter. 
26 
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1 Multiple different Condition Lists 114 are available in this 

' 2 embodiment to provide a range of choices to physicians, and 

3 six are shown, by way of example. Three of these lists 114 

4 classify conditions broadly by diagnosis (Dx) and comprise a 

5 system-maintained Dx-Personal list 114, an alphabetically 

6 organized Dx-Alphabetic list 114 of all conditions in the 

7 system and a Dx-Category list 114. Dx-Category list 114 

8 lists conditions by broad therapeutic category such as 

9 cardiovascular, GI or dermatology. A fourth condition, 

10 problem or diagnosis list, Dx-Patient list 114 lists 

11 previously exhibited conditions or problems of the selected 

12 patient, in this case, Mary Harrington. Dx-Patient list 114 

13 is system maintained (and manually supplementable) and 

14 changes according to the patient selected in the patient- 

15 selection screen of Figure 2. Dx-Personal list 114 is also 

16 system maintained (and manually supplementable) and changes 

17 according to which prescriber signs on. 
18 

19 Preferably, the system includes frequency counters to track 

20 the conditions the user encounters with time, and the counts 

21 obtained are used automatically to maintain or generate a 

22 Dx-Personal list 114 for the user, which more closely 

23 portrays patterns of conditions encountered in the user's 

24 practice as time goes by. Base periods for reporting usage 

25 may be varied, or user selected, to list conditions 

26 encountered by frequency in, for example, the last year, the 
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1 last five years, or perhaps, the last three months. Also, a 

2 default can be included to highlight a selected patient T s 

3 last active condition or conditions as a first-line choice . 
4 

5 Preferably, any time a new diagnosis is made, the new 

6 condition encountered is placed in the user's Dx-Personal 

7 list 114 and any time a drug is chosen it is placed in a 

8 personal drug list for the user. The first time either a 

9 condition or a drug is selected, it is added to a user 

10 profile stored on the network, for example, at the host 

11 computer facility. 
12 

13 In addition, a physician-user can manually maintain one or 

14 more custom lists, Dx-Custom 1 list 114 and Dx-Custom 2 list 

15 114, for their own preferred short lists of conditions 

16 being, for example, conditions appropriate to their 

17 specialty that the individual physician frequently 

18 encounters for treatment. Alternatively, libraries of 

19 specialty lists may be made available from which the user 

20 selects one or two lists for their personal use. Such 

21 custom lists 114 may be associated with different user 

22 activities, for example, Dx-Custom 1 could be used at a 

23 hospital where the user is an attending physician, while Dx- 

24 Custom 2 is used at a pain clinic where the user is -a 

25 visiting physician. The various condition lists 114 
2 6 provide alternative pathways to drug selection that a 
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1 physician may use as an aid to deciding upon a course of 

"2 treatment. Different pathways may suit different clinical 

3 circumstances or prescribers. Availability of alternative 

4 routes to relevant drugs may enable a physician to find 

5 improved treatments, and increase their range of choices, 

6 and may lead to new solutions to difficult prescribing 

7 situations. 
8 

9 The condition list selection screen shown in Figure 4 is a 

10 gateway to other condition and drug selection screens. As 

11 an alternative for quicker selection, a preferred condition 

12 list (typically a Dx-Personal list 114) could be set as a 

13 default with other condition lists 114 being reached via a 

14 Change Condition List burton (nor. shown) . 
15 

16 Any or all condition lists 114 can be automatically 

17 supplemented or maintained by the sysrem as it receives data 

18 in the course of processing numerous prescriptions for one 

19 or more physician users. In addition to supplementation 

20 with user-originating data, preferred embodiments maintain 

21 user profiles on a host computer facility which continually 

22 refreshes the data at the user's device so that the user can 

23 use any device or share a device with other users. 
24 

25 Condition selection 

26 In the Select Condition screen of Figure 5, the patient 
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1 condition 116 in the Dx Personal category shown comprise 

2 generalized groups of disease, some serious like diabetes 

3 and pneumonia, and others less so, for example rhinitis or 

4 sinusitis. More complex embodiments than the one shown here 

5 may categorize conditions into as many as four or five 

6 different columns of subcategories of condition according to 

7 disease pathology, therapy, personal knowledge and so on. 

8 Such condition categorization, as a preliminary to drug 

9 listing, provides a very powerful tool for physicians to 

10 view their prescribing options on screen and to organize 

11 them. Organization of drugs by lists of effectively treated 

12 patient conditions enables a user intelligently to access a 

13 large body of drug data selections. This approach provides 

14 multiple mapping so that the user can find a suitable drug 

15 or selection of drugs via different pathways according to 

16 their preferred work methods. 
17 

18 Different pathways to a drug via conditions organized in 

19 other ways, notably by body system, are illustrated in 

20 Figure 8, described 'hereinbelow. Direct pathways of drug 

21 selection using drug lists are illustrated with reference to 

22 Figures 9 and 10, described hereinbelow. 
23 

24 In the example shown in Figure 5, the user-physiciarv has 

25 highlighted and selected a patient condition 116, namely, 

26 peptic ulcer disease (PUD) /gastritis, displaying, in the 
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1 next right-hand column (see Figure 6), a short, system- 

"2 generated list of drugs known to be therapeutically 

3 indicated for PUD/Gastritis and which may be suitable for 

4 prescription or to have been prescribed in the past by that 

5 user for treating these conditions. The presence of the 

6 user's previously prescribed drugs , which may not 

7 necessarily appear on third parties' lists, helps 

8 personalize the list to the user. 
9 

10 Referring to Figure 6, now that a condition, PUD/Gastritis, 

11 has been selected, a new screen title, Select Drug 111, 

12 appears and selection of a drug to treat this condition 

13 proceeds. To aid the selection, a condition-specific, 

14 formulary drug list 118 is displayed in the next right-hand 

15 column of the Select Condition screen of Figure 6 under 

16 Formulary Drug header 120. Alternatively, a physician's 

17 personal list of drugs may be displayed with formulary drugs 

18 highlighted. If desired, relative cost information can be 

19 included or alternative drugs may be ranked by preference of 

20 the formulary manager. 
21 

22 Formulary Drugs are those listed by a drug formulary 

23 specified by, or relevant to, the patient, in this case, 

24 Mary Harrington. The drug formulary may be generated by a 

25 prescription benefits management company and is a key 

2 6 ingredient in a system for reducing overall prescription 
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1 costs by using volume purchasing to get preferred pricing on 

'2 selected drugs. 
3 

4 A major problem in fulfilling the cost-control objectives of 

5 a managed care organization is that of informing a 

6 prescribing physician as to which drugs are in the formulary 

7 for a given patient. Noting that there are many different 

8 formularies it is quite impractical for the average 

9 physician to keep referencing different formularies for 

10 every patient every time they write a prescription. The 

11 aspect of the invention shown in Figures 6 through 11 helps 

12 solve this problem by providing computer access of remote 

13 databases containing the information and by presenting 

14 available formulary drugs in a form which is easy for a 

15 physician to use, reference and prescribe without enforcing 

16 physician compliance with a formulary f s treatment guidelines 

17 and attempting to restrict a physician's exercise of their 

18 professional judgment. 
19 

20 To the contrary, the system of this invention is designed to 

21 empower a physician to make informed choices at the point of 

22 care. The system fosters quality, cost-effective 

23 prescribing. Physicians do. not have to attempt to remember 

24 drug formularies and formularies may be changed with instant 

25 effect on all users without having physicians relearn the 

26 formulary. Where formulary information is called across a 
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1 data-retrieval network, each time it is required, in 

2 accordance with preferred embodiments of the invention, from 

3 a remote source database, updates are automatically posted 

4 across the network. 
5 

6 Nonformulary drugs may be substantially more expensive than 

7 formulary drugs, or may not be covered by the patient T s drug 

8 benefits plan, and may require our-of -pocket payments by the 

9 patient which circumstance may cause administrative problems 

10 to the physician and be a burden to the patient. Worse 

11 still, the patient may not have the prescription filled. 
12 

13 By including pharmacy-derived prescription fulfillment 

14 information, a patient prescription history can indicate 

15 whether a patient actually received a medication. The 

16 physician can be alerted (by e-mail) if a patient has not 

17 filled a prescription for a critical medication, for example 

18 LASIX (Hoechst), prescribed for hypertension, enabling a 

19 follow-up with the patient to be initiated. 
20 

21 Where formulary drugs are professionally acceptable to the 

22 physician and of equivalent therapeutic effect to non- 
23 formulary drugs, failure to, use them is clearly undesirable. 

24 This problem is overcome by the present invention. .If the 

25 physician is satisfied with the formulary drugs offered by 

26 the prescription management system of this embodiment, 
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1 anyone may be selected and automatically posted to the novel 

2 prescription described herein as will be described* 
3 

4 Prescribing non-formulary drugs 

5 Should the physician know, for example; that cimetidine and 

6 ranitidine, drugs in a similar class, have been tried and 

7 found ineffective and that the condition is well beyond 

8 these first line treatments, so that none of the formulary 

9 drugs is suitable, then the physician can select Other, 

10 which selection displays a nonf ormulary drug list 122, under 

11 nonf ormulating drug header 124, as shown in Figure 7. In 

12 this case, the physician selects Sucralfate as being a non- 
13 formulary drug in a different chemical category and having 

14 somewhat different therapeutic properties from those 

15 previously applied to treatment of this patient's symptoms. 
16 

17 Having made the decision to select Sucralfate, the physician 

18 is informed by the system display shown in Figure 7 that 

19 sucralfate is a nonformulary drug not on patient Mary 

20 Harrington's prescription benefit management company T s 

21 schedule. With this timely notification in hand, the doctor 

22 can, if appropriate, consult with a patient, explain the 

23 reasons for his or her drug selection and gain the patient's 

24 agreement to assuming the cost of the prescription, .or 

25 obtain authorization from the plan to cover the cost of this 

26 prescription for this exceptional case. Physicians 
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1 manifesting increasing compliance flowing from use of a 

"2 prescription management system according to this invention 

3 can expect ready approval of a non-formulary drug on a 

4 justified exceptional basis. 
5 

6 By tying a diagnosed condition to a prescribed drug and 

7 requiring a condition to be recorded as a treatment 

8 objective before a prescription is fulfilled, new drug 

9 formularies can be created where prescribing of a drug is 

10 qualified according to the condition treated. For example, 

11 an expensive drug like captopril may be a first-line 

12 formulary choice for an acute condition such as congestive 

13 heart failure, but not a first-line choice, or may even be 

14 excluded as non-formulary, if prescribed for a chronic 

15 condition such as hypertension. 
16 

17 In practice, after the system learns the user's preferences, 

18 most condition and drug selections will be quickly made from 

19 the user's preferred or custom lists or from historically 

20 derived patient lists of previously encountered conditions, 

21 or previously prescribed drugs. The system adapts to the 

22 prescribing user to enable rapid creation of routine 

23 prescriptions. A minority of situations may call for less 

24 obvious therapies or therapies with which the physician has 

25 little or no experience. Physicians tend to be most 

26 reluctant to prescribe new drugs. Responsible physicians 
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1 will usually scrutinize a great deal of relevant information 

*2 before prescribing a drug for the first time. This effort 

3 is captured by the system which enables a prescriber to have 

4 quick access to their prior experience and confine their 

5 drug selections to drugs they have used previously and which 

6 were satisfactory. (A physician can of course edit their 

7 personal list to remove drugs that proved unsatisfactory for 

8 some reason or another, whether therapeutic or not, or they 

9 can be removed automatically based on decreasing frequency 
10 of use . ) 

11 

12 In other circumstances a physician will need to select a 

13 drug with which they have little or no experience. Here, 

14 when it is most needed, the system provides major support 

15 and reassurance, presenting several different pathways to 

16 appropriate solutions enabling online access to the latest 

17 available scientific, clinical and commercial information 

18 about a new drug as well as screening for complications. 

19 The ability to offer drug detailing at the point of need for 

20 new drug information can be used to attract revenue from 

21 pharmaceutical companies, managed care companies or others, 

22 and is especially useful in decreasing the barriers to 

23 switching to first-time use. of a drug. The system-provided 

24 prescribing information resources that are brought to the 

25 point of care are also valuable in enabling a physician to 

26 make quick therapeutic substitutions. 
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1 The drug selection screen shown in Figure 8 offers, by way 

2 of example, one route to selecting a new drug not on the 

3 prescribed s short lists. Here, selection is condition 

4 driven and proceeds with the selection of a condition list 

5 114, Dx by Body System or Dx by Therapeutic Class, and then 

6 locating a drug to treat that condition; or alternatively, 

7 by directly selecting a drug via drug lists 115 Rx by 

8 Therapeutic Class or Rx by Alpha. Displayed in Figure 8, 

9 reading across the columns from left to right, are a list of 

10 body systems 117 from which the prescriber has selected 

11 Musculoskeletal. In the next right column the system 

12 displays a list of conditions 116 that might be displayed by 

13 the musculo-skeletal system, of which nine are listed by way 

14 of illustration. From these nine the prescriber has 

15 selected Osteoarthritis. Osteoarthritis is posted to 

16 Condition field 86 in prescribing zone 44 of prescription 

17 creation screen 39 (Figure 3) . 
18 

19 With a condition specified, selection proceeds to the 

20 choosing of a drug to treat the condition of osteoarthritis. 

21 Drug selection proceeds through a preliminary selection of 

22 drug category, from a list of drug categories 119 in the 

23 next column to the right, enabling the prescriber to choose 

24 their therapeutic approach, in this case, as between' 

25 employing an analgesic, a narcotic, a NSAID (non-steroidal 

26 anti-inflammatory drug) or a salicylate. A NSAID is chosen, 
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1 generating an expensive list of drugs 121 in the right most 

"2 column in Figure 8, from which the prescriber can make their 

3 final selection which will be posted to Drug field 88 in the 

4 prescription creation screen 39 (Fig. 3) . 
5 

6 The complexity of the prescribing process is graphically 

7 illustrated in Figure 8. Even after narrowing the field 

8 down to a specific class of drugs, NSAIDS, for treating a 

9 particular symptom, osteoarthritis, there are still of the 

10 order of fifty drugs from which the prescriber makes a final 

11 selection. 
12 

13 

14 Direct drug selection 

15 Prescribers often know what drug they want to prescribe and 

16 will wish to access it very quickly, and may not use the 

17 system if they are unable to do so. This goal can be 

18 reached with user-adaptive personal drug lists organized to 

19 default to a prescriber 1 s preferred choices, as described 

20 herein. 
21 

22 One preferred user-adaptive approach to providing a quick- 

23 prescribing pathway to a prescription is for the system to 

24 process the user's personal drug list, to highlight „ ■ or 

25 short-list or otherwise present those drugs on the personal 

26 list that are appropriate therapy for any of the patient's 
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1 active conditions, and preferably also, that are on the 

2 patient 1 s formulary. 
3 

4 Referring to Figure 9, an alternative direct drug- 

5 specification pathway commences, reading from left to right, 

6 with selection of drug list 115 Rx by Therapeutic Class. 

7 From a list of perhaps fifty to one hundred drug categories 

8 119 which appears in the next right hand column, the 

9 prescriber has picked Diuretics, generating an even longer 

10 list of diuretic drugs 121 from which the prescriber has 

11 picked Dyazide (trademark, Smith Kline Beecham) . The system 

12 now calls for entry of a condition, in this case 

13 "hypertension". The extent of the lists of drug categories 

14 119 and diuretics 121, again illustrates the bewildering 

15 array of drug selections with which a prescriber is 

16 confronted. An otherwise uncertain or overly conservative 

17 decision-making process can be rendered efficient, reliable 

18 and manageable by a prescription management system according 

19 to the invention. 
20 

21 The selection program illustrated in Figure 10 provides a 

22 variety of pathways for direct drug selection via five drug 

23 lists 115, a personal, an alphabetic, a category list and 

24 two custom lists, analogous to condition lists 114.: "Here 

25 the user has selected Rx-Alphabetic list 115 and the system 

26 has displayed a portion of a long, scrollable list of drugs 
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1 121 in the next column. This approach can quickly locate a 

2 target drug when the physician knows it by name. Here 

3 Cefixime has been selected and the system calls for, and 

4 requires, the prescriber to enter a condition before 

5 proceeding to quantification of the prescription. In the 

6 next column the system lists conditions that the user has 

7 previously treated with Cefixime, highlighting the most 

8 recent condition so treated, or the system may display a 

9 previous condition of this patient that was treated with 

10 cefixime, not necessarily by the current user. If the 

11 physician wishes to attack some other condition with 

12 cefixime, such other condition may be selected from the last 

13 righthand column, activated by "other". 

14 The diversity of conditions treatable with cefixime 

15 illustrates the potential for outcome studies based upon 

16 widespread use of systems according to the invention to 

17 refine definitions of the therapeutic scope of individual 

18 therapeutic agents by collecting data on effective new 

19 applications and on precautions, interactions and side 

20 effects. 
21 

22 Some advantages of condition-specified drug prescribing 

2 3 Being abundantly served at the point of care with relevant 

24 prescribing information at the critical moment of decision, 

25 the physician can eliminate many subsequent problems or 

26 difficulties which may lead to unnecessary paperwork, or 
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1 surprised, annoyed or non-compliant patients, and to 

'2 unnecessary phone calls between pharmacist and physician 

3 when a patient learns only at the pharmacy that their 

4 prescription is non-formulary. The system can eliminate 

5 much unnecessary "phone tag" between pharmacies and 

6 physicians. Improved physician and patient compliance with 

7 preferred guidelines will reduce the cost of care and 

8 increase the quality of care. 
9 

10 The availability, by means of the invention, of vital drug 

11 selection information, categorized by therapeutic condition 

12 and denoted as formulary or not, for the patient in 

13 question, rapidly assembled, preferably from remote source 

14 data, and conveniently presented to a physician for flexible 

15 use in their own personal work flow, greatly enhances 

16 prescribing practices, fosters cost containment and eases 

17 the administrative burdens that fall on heavily prescribing 

18 physicians. It enables informed choice at the point of care 

19 leading to a decrease in adverse outcomes of therapeutic 

20 choices. 
21 

22 Naturally the prescription management system of the 

23 invention can provide a variety of printed reports and other 

24 data outputs of any facet of the described operations. In 

25 some cases, these reports can be enhanced to provide 

26 entirely new products for example a dosing schedule such as 
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1 that described with reference to Figure 15, and shipping 

2 schedules or split prescriptions divided according to 

3 suppliers requirements. 
4 

5 Current and historical reports can, subject to the access 

6 controls described herein, be patient-specific, prescriber- 

7 specific or organization-specific and can be aggregated 

8 across various groups, pools, geographical regions, 

9 conditions, drugs, or time periods or combinations of any of 

10 the foregoing to provide a valuable data resource to health 

11 care providers, patients, managed care organizations, 

12 government agencies and others. 
13 

14 Further to enhance the prescribing decision process, 

15 additional features can be included on screens such as 

16 Figure 7, for example drug pricing information, employing 

17 actual wholesale or retail pricing, or comparative pricing 

18 or on another manner of drug pricing or grouping, such as a 

19 comparative scale or price rating system, or relative 

20 pricing based on actual prescription benefit management 

21 company contracts. Such pricing information can greatly 

22 influence M.D. decision-making, improving formulary 

23 compliance and reducing overall drug costs, without 

24 restricting a physician T s choices. 
25 

26 A powerful optional feature of the invention is shown in 
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1 exemplary fashion by the drug evaluation screen depicted in 

"2 Figure 11. After a physician selects a drug from one of the 

3 screens of Figures 7 to 10, the system can optionally scan a 

4 drug preference database of preferred drug treatments for an 

5 evaluation of the merits of the selected drug in treating 

6 the condition. The drug preference database may be remote 

7 and may be maintained, for example, by a managed care 

8 organization, HMO, or prescription benefits management 

9 company. As the Figure 11 example shows (which example 

10 employs different condition and drug selections from those 

11 used in Figures 6 and 7) one possible result of the database 

12 scan may be an on-screen report with an alert message, in 

13 header 126 advising the physician that the selected drug is 

14 "Not a first line drug" for treating the selected condition. 

15 As a helpful suggestion to the physician the system can also 

16 offer alternative drugs, from listings in the drug 

17 preference database, as being more meritorious for the 

18 treatment of the condition in question (pursuant to the 

19 maintaining benefit company's standards or, preferably, to 

20 objective literature reports) . 
21 

22 To this end, the drug selection evaluation screen of Figure 

23 11 comprises an explanatory . box 128 elucidating header 126; 

24 an alternative drug selection menu 130; and at the bottom of 

25 the screen, three action buttons; for example, Tx Guidelines 

26 132 to access treatment information about the alternative 
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1 drug highlighted in menu 130; a confirm button 134 to post 

2 the physician's original drug selection, in this case 

3 "Cefixime" and to return to prescription creation screen 39; 

4 and a cancel button 136 which returns the user to the drug- 

5 selection of Figure 7. 
6 

7 The treatment information available via Tx Guidelines button 

8 132 may include a literature reference supporting the 

■9 system's finding that Cefixime is not a preferred first line 

10 agent for treatment of the selected condition, otitis media. 

11 Optionally there may be a selection on a drop-down menu from 

12 the Tx Guidelines button 132 enabling a physician, without 

13 further effort to have a copy of such a study sent to them. 

14 In a further optional embodirr.en- , Tx Guidelines button 132 

15 can provide the user with an access point to full disclosure 

16 and prescribing information on zhe drug. Available 

17 treatment guidelines information can include details of the 

18 particular conditions for which a system suggested 

19 alternative drug has been found effective, adverse 

20 conditions, preferred dosages and administration routes, 

21 literature sources and so on. This aspect of the inventive 

22 system provides a simple, nonintrusive technique for 

23 bringing new drug information to physicians at a critical 

24 moment of need, when creating a prescription. 
25 

26 Although described as a self-contained system, it will be 
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1 appreciated that functions such as the identification and 

'2 listing of drugs via conditions treated, and patient 

3 prescription histories will have value in other systems, for 

4 example, patient encounter management systems, and may be 

5 accessed directly from such systems via a prescribing 

6 information button. 
7 

8 As well as compensating for error or lack of information on 

9 the physician-user's part, the prescription review system 

10 exemplified in Figure 11 has great value as an educational 

11 tool. Physicians can be subtly trained to improve their 

12 drug selection behavior. By using the system aggressively 

13 and exploring its information resources, as they are 

14 encouraged to do by the system's prompts and alerrs, 

15 physician prescribers effectively receive education and 

16 training at the point of care. Improvements in drug therapy 

17 are subtle and complex and it is often difficult, even for 

18 the most conscientious of physicians, to be abreast of 

19 developments in any more than one narrow field of medicine. 

20 It is just as difficult for purveyors of new drugs to break 

21 in to a physician's packed work schedule to educate them as 
22' to the merits of a valuable new drug. 

23 

24 More than one alternative drug may be offered. Also -in an 

25 optional embodiment not shown, the physician user may choose 

26 to display a screen of drug information regarding the 
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1 alternative drug or any other drug. After confirming a drug 

"2 selection the system can review the patient's history in 

3 relation to the selected drug and alert the physician to any 

4 relevant allergies, one-on-one drug interactions or, if 

5 appropriate, multiple drug interactions. 
6 

7 Often, when new drug information is presented, a physician 

8 is unable to consider it, yet when the information is 

9 needed, or could be used, for example at the point-of-care, 

10 when creating a prescription, valuable new drug information 

11 may be unavailable or forgotten. This invention solves that 

12 problem by presenting new drug information in a timely 

13 manner at the moment when it is most needed and a pnysician 

14 is most interested in considering it, namely at the ~ ime of 

15 writing a prescription. It gives a benefit management 

16 company the opportunity to influence a physician's choice at. 

17 the most influential moment, during the prescribing 

18 decision . 
19 

20 User-adaptive drug formulary compliance 

21 Conventional formulary guidelines specify one or more 

22 substantial lists of preferred drug therapies. Many of 

23 these drugs will be unfamiliar to most prescribers who will 

24 therefore be reluctant to prescribe them. Natural 

25 professional prudence makes most physicians extremely 

26 cautious about specifying powerful agents for therapeutic 
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1 goals when they have little or no prior experience with the 

'2 agents but will be responsible for the outcome of the 

3 treatment . 
4 

5 The system of the invention can provide a novel approach to 

6 drug formulary management whereby prescriber-centric 

7 formularies can be established. By means of the system, 

8 drug formulary guidelines effectively adapt to the user's 

9 prescribing patterns or can be followed effortlessly by the 

10 prescribes This desirable prescriber-centricity can be 

11 obtained by giving priority to the prescribed s personal or 

12 custom lists or, better still if they are a subset of these, 

13 to the patient ! s history lists, and system-identifying 

14 patient-formulary preferences on those lists for easy final 

15 picking by the prescribes Where the prescriber is 

16 selecting a drug providing effective therapy for a just- 

17 specified condition, the above procedure may often clearly 

18 identify a single drug meeting all requirements or may 

19 result in a short list of a very small number of drugs for 

20 final selection. Where no drug is listed as meeting all 

21 requirements, the system may so alert the user and suggest 

22 formulary drugs not on the doctor-specific lists or ask the. 

23 user whether they wish to review appropriate non-formulary 

24 drugs from their personal or custom lists. 
25 

26 
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1 Patient's prescription history 

" 2 Figure 12 shows a prior prescription information screen 

3 which can be displayed by double clicking the prescription 

4 display line or activating RX History button 54 in a screen 

5 zone such as prescription history zone 43 of prescription 

6 creation screen 39 shown in Figure 3. The embodiment of 

7 screen shown in Figure 12 provides a simple passive 

8 information display, comprising an information box 138, a 

9 close button 140 and a scroll bar 142 for scrolling or 

10 browsing a library of prescription histories. The displayed 

11 prior prescription information in box 138 comprises, for the 

12 selected prescription, the condition for which the drug was 

13 prescribed, the drug name, date of prescription, dates of 

14 any renewals and the name, phone number and any other 

15 appropriate identification of the prescribing physician, in 

16 this case it is the user physician, and any other useful 

17 details that may not be strictly prescribing information, 

18 including appended free text, voice annotations or other 

19 electronic ink. Where an "N" indication appears in the Mine 

20 column 76 on the prescription history line in Figure 3, the 

21 name of another physician who authored the relevant 

22 prescription will appear in Figure 12. 
23 

24 In addition to conveniently presenting useful historical 

25 prescription-related details, powerful optional features, 

26 for example, direct E-Mail communication with the physician 



-115- 

1 whose name is displayed (or with some other physician) can 

'2 be activated from the prescription information screen of 

3 Figure 12 or other suitable screen, can be included in the 

4 prescription management system of the invention. Such 

5 options enable physicians to send an inquiry to, and perhaps 

6 retrieve relevant records directly from another physician 

7 such as a previous prescriber to the patient, or a referring 

8 physician. The invention facilitates the execution of such 

9 information transports during the user-physician T s encounter 

10 with their patient. The screen of Figure 12 could 

11 additionally have an Auto Dial button and be linked to other 

12 modes of communication to facilitate a direct connection to 

13 the physician of interest. Additional options include a 

14 display of historical dosage information and an ability to 

15 page through all prior prescriptions or all prescriptions 

16 for a given patient, a given prescriber, a given condition, 

17 a given therapeutic class, and so on, recapping some of the 

18 functionality of the Figure 3 prescription creation screen 

19 39. 
20 

21 A further optional feature of the invention is shown in the 

22 patient problem or condition screen of Figure 13, openable, 

23 for example, from Problem button 50, Figure 3, which tracks, 

24 as indicated by the field headers 144-156 extending -across 

25 the screen, a history of the patient's problems and records 

26 diagnostic determinations regarding individual problems. 
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1 in particular, the system captures information regarding the 

' 2 date when a new problem first becomes active and when it is 

3 "deactivated". These dates are associated with the name of a 

4 physician user, and thence with a patient encounter and can 

5 be regarded as authentic diagnostic determinations capable 

6 of being substantiated from the physician T s office records. 

7 Additional information screens, detailing, for example 

8 laboratory or other diagnostic data, or relevant personal 

9 patient characteristics, for example height and weight, can 
10 be linked to problems as they are with drugs. 

11 

12 By processing such reliable base data, combined with 

13 historical prescription data associating a patient prooiem, 

14 or treatment category, or treatment objective, with a 

15 prescribed drug routine, valuable new information and 

16 outcome studies can be generated. For example, the duration 

17 of problems in relation to particular treatments can easily 

18 be calculated. 
19 

20 Using the Figure 13 screen the system user, or the system, 

21 labels a problem or condition as new in New field 144; 

22 describes the nature of the problem in Problem field 14 6 

23 from a condition list (not shown) such as condition list 114 

24 shown in Figure 4; selects a "Y" or "N" flag in Act. field 

25 148 to show the status of the condition as active or not; 

26 inserts the name of the physician adding the problem to the 
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1 list in Diagnosing Physician field 150 (which the system 

2 will default to the current user) ; inserts the date the 

3 problem was added in Date field 152; inserts the name of the 

4 physician determining the problem is resolved or no longer 

5 active in Resolving Physician field 154; and inserts the 

6 date of resolution in Date field 156. Thus changes to the 

7 patient record are stamped with the name and date of the 

8 responsible physician to provide an audit trail. A 

9 physician identifier can be added if desired. 
10 

11 Problems that no longer manifest themselves to the patient 

12 or physician can be indicated as not active in Act field 

13 148. The problem list can be sorted by header selection and 

14 preferably presents active problems at the top of the list 

15 by default. 
16 

17 Such a system-maintained problem list provides an easy and 

18 convenient reference to the patient 1 s history of conditions 

19 or problems and of the duration and currency of such 

20 problems and constitutes a valuable case management tool for 

21 physicians. The problem list is automatically supplemented 

22 during the prescribing process with the latest prescriber's 

23 latest observations and diagnoses, as indicated by selection 

24 of one or more conditions for posting to a new prescription. 
25 

2 6 Where a patient complains of an old problem a quick 



-118- 

1 prescription creation routine comprises selecting the 

"2 problem from the Dx-Patient list 114, then selecting a drug 

3 from a system-generated pick list of drugs providing 

4 appropriate therapy for that condition. The pick list is 

5 preferably drawn from the doctor's personal list and is 

6 either compliant with the patient's formulary guidelines, or 

7 indicates those guidelines, for example by inverse video, 

8 highlighting or the like, and also includes a selection of 

9 "other" to access drugs not on the prescriber's personal 

10 list. Such a quick prescription routine enables the most 

11 routine situations to be promptly handled, yet permits the 

12 physician to expand their prescribing horizons and does not 

13 merely require selection of the same drug as was used 

14 previously. Quick treatment substitutions are made possible 

15 by the system's presentation of available alternative 

16 therapies enabling the prescriber easily to see what 

17 alternatives are available and to explore those with which 

18 they are unfamiliar. 
19 

20 Also the problems or conditions on this list can be 

21 automatically posted to a patient problem list 114 to appear 

22 as an additional "Dx" list in screens such as those shown in 

23 Figures 4-10, to provide quick selection or review of a 

24 patient 1 s historical conditions. Preferably, such aDx- 

25 Patient list 114 changes automatically when another patient 

26 is selected. 
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1 As various system-using physicians, laboratories and the 

' 2 like encounter the patient or provide services to the 

3 patient, they become original sources for new record 

4 elements memorializing their encounter with the patient or 

5 the patient's attributes. The patient ! s history 

6 accumulates, and the system compiles, on demand, a 

7 cumulative virtual patient record including all newly 

8 created record elements. This current patient history 

9 record is promptly available to any authorized physician 

10 user on the network. In an ideal world, all relevant 

11 encounters are captured so that the patient's record is 

12 comprehensive or complete. 
13 

14 The value to a patient's care givers, of an instantly 

15 available, comprehensive patient record cumulatively 

16 reflecting all current and recent medications and 

17 conditions, is immense. Its availability to emergency 

18 personnel may be life saving. 
19 

20 The problem list screen of Figure 13 is accessed from 

21 prescription creation screen 39 (Figure 3) by pressing 

22 button 50. Selecting an OK button 158 or Cancel button 

23 160, the problem list returns to prescription creation 

24 screen 39 (Figure 3). Change Status button toggles.the 

25 highlighted Act entry between "Y" and "N", and records a 

2 6 date and physician name with any status change. Add button 
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1 164 enables a physician user to add a new condition to the 

2 list, using condition selection pick lists, as previously 

3 described. This routine may be used to note problems for 

4 which there is no specific prescription given, e.g. obesity 

5 or senile dementia. 
6 

7 Where the inventive prescription management system is 

8 applied to statistical data collection for outcome studies, 

9 it is preferable to supplement the patient record with a 

10 range of relevant personnel data, to the extent that this is 

11 available, for example drug abuse behavior, smoking and 

12 habitual eating or drinking behavior, dietary habits, 

13 marital and family status, pregnancies, ethnicity, 

14 environmental factors, and so on. The system provides an 

15 excellent means for tracking these factors and their changes 

16 as they may pertain to an individual's health. For example, 

17 data fields could be added to record any of the foregoing 

18 data and the data could be updated by medical or 

19 administrative personnel in preparation for a patient- 

20 physician encounter. 
21 

22 Of particular significance to outcome studies will be death 

23 certificate information, and preferably this information is 

24 added to the patient problem record of Figure 13, as- 

25 appropriate. 
26 
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1 More complex embodiments of the invention can integrate 

"2 applications for prescription management with equivalent 

3 applications for diagnostic tests, laboratory analyses, and 

4 radiological studies to provide a more comprehensive patient 

5 history viewable in multiple screens. Of particular value 

6 in such an integrated presentation are laboratory results 

7 providing drug dosing levels, renal and liver function tests 

8 that provide important indications as to appropriate dosing, 

9 and so on. 
10 

11 Figure 14 shows a manually maintainable problem record 

12 maintenance screen, for physician use, which can be accessed 

13 for example from the Doctor's lists button 24 in tne system 

14 entry screen of Figure 1. This screen enables a doctor or 

15 physician manually to maintain their own personal customized 

16 prescription, diagnosis, allergy or other useful lists, to 

17 supplement the automatically maintained system lists. If 

18 desired, problems the doctor f s patients have experienced 

19 previously can be system-added to the list, for example when 

20 a patient is selected. These personalized lists or profiles 

21 are posted to the network where the system can retrieve them 

22 to any user interface device via a host computer facility, 

23 subject to appropriate password protection or the like. 

24 Relying upon such centrally stored personalized profile 

25 files, the system can present a customized, personal 

2 6 appearance, with familiar configurations, attuned to the 
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1 user's work habits, at any geographical location from which 

"2 the network can be accessed. 
3 

4 The problem record maintenance screen of Figure 14 comprises 

5 a Problem List box 166, a List Type box 168 and a Problems 

6 box 170 displaying a comprehensive, or preferably exhaustive 

7 list of problems which can be selected and transferred to 

8 the network and the physician's problem list by pressing 

9 update button 172. Highlighted entries can be removed from 

10 the Problem List 166 by pressing delete button 174. Save 

11 button 176 and Exit button 178 perform the usual functions, 

12 and preferably provide options to cancel changes, and the 

13 like. Data entry box 180 permits an unlisted condition to 

14 be keyed in, or otherwise entered character-by-character and 

15 paging buttons 142 move between lists. 
16 

17 Archiving 

18 Given the medical, commercial and legal significance of the 

19 transactions executed and the data generated by use of the 

20 system of the invention described herein, as well as the 

21 value of that information to the patient, the physician and 

22 many other organizations, maintenance of accurate historical 

23 records, or archiving, is desirable, or essential, and 

24 preferred embodiments of the invention provide archiving at 

25 a host computer facility 106. 
26 
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1 Data storage burdens attendant upon long-term archiving are 

2 substantially relieved by using virtual patient records, as 

3 described herein. Pursuant to the principles relating to 

4 the use of virtual patient records dynamically created from 

5 source data record elements, the invention prefers to 

6 archive such data as will enable a full and accurate record 

7 of the past to be regenerated from diverse sources, rather 

8 than recording the past verbatim. Date and time stamped 

9 record elements allow recreation of a virtual patient record 
10 at any point in time. 

11 

12 Preferably, the data logged into archives comprise all data 

13 relevant to a patient's diagnosis and therapies, data 

14 relevant to the user's prescribing activities, including the 

15 prescribed s relevant electronic communications ("e-mail") 

16 with third parties {pharmacies, laboratories, other health 

17 care providers, or potential providers, to the patient, and 

18 so on) and access audit data as to parties accessing the 

19 patient's or prescribed s personal data. 
20 

21 System- support infrastructure 

22 Referring to Figure 16, the lefthand side of the diagram 

23 shows an arrangement of services and devices that provide a 

24 downstream flow of data and communications resources- to 

25 users of the prescription management, or other system 

26 described herein. The righthand side shows sources from 
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1 



which desired data and data elements may be drawn and 



2 



pathways for those data to reach the user, the flow being 



3 



marshalled by a centrally depicted host computer. 



4 



5 Shown schematically in Figure 16, are a number of user 

6 interface devices 200 and a desktop computer 201 

7 communicating via any of a variety of communication services 

8 202, through a gateway-router 204 with a hosr computer 

9 facility 206. The drawing depicts schematically how a group 

10 or pool of users working with interface devices 200 or 

11 computers 201, running the prescription management software 

12 of this invention, can be serviced by host computer facility 

13 206. Those skilled in the art will appreciate that the 

14 schematic layout shown in Figure 16 is described in terms of 

15 its logical architecture and that the actual physical 

16 disposition of elements may be quite different. 



18 Tn addition to coordinating system-related communications, 

19 especially retrieval of source data from remote databases, 

20 gateway-router 204 can manage supplementary services such 

21 for example as a paging service 208 or any other relevant 

22 desired' function. 



24 Interface devices 200 are depicted as small form factor, 

25 handheld devices, or PDA's, communicating wirelessly over a 

26 WAN, a proprietary wireless service, or a cellular digital 



17 



23 
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1 packet data service, or the like. Desktop computer 201, 

2 which may be a portable, notebook or other higher form 

3 factor computer, connected to communications gateway-router 

4 204 via a local area network labeled LAN^ which connection 

5 could equally well be via modem, infra-red, wireless or the 

6 like, depending upon the circumstances. Any suitable 

7 network may be used, depending upon the user's equipment and 

8 the location of desired resources. Wired or wireless, local 

9 or wide area networks, or mixed networks, are suitable. 
10 

11 Routing to the appropriate service and other communications 

12 technicalities are coordinated by communications gateway- 

13 router 204 which is networked or otherwise connected with 

14 host computer facility 206. 
15 

16 Other prescribers (or other professionals in different 

17 environments) may use different methods to communicate with 

18 host computer facility 206 using a two-way digital data 

19 communication system across a network. 
20 

21 Still other users may be supported by other host computer 

22 facilities communicating in their turn with host computer 

23 facility 206 using appropriate network services and 

24 providing communication links or pathways between such other 

25 users and physician users supported by host computer 

26 facility 206. Such organizations employing one or more 
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1 each of both users and host computer facilities are intended 

2 by references herein to "network" or the "network", 
3 

4 Communication services 202 can be any service providing 

5 effective two-way data transfer between users 200 and host 

6 computer facility 206. As labeled, some possible 

7 communication services 202 are wired local area networks 

8 "LANt . . . LAN-" , wireless local area networks "WLAN : . . . WLAN n " 

9 and proprietary radio frequency packet data networks, such 

10 as ARDIS and RAM (trademarks of their respective 

11 proprietors), cellular digital packet data networks 

12 "CDPD,. . .CDPD n " and so on. 
13 

14 Not shown is a wire telephone connection between a user 

15 device 200 and communications gateway-router 204. This is 

16 of course a possible embodiment of the invention and it is 

17 also, to be understood, local area networks LAN n , could 

18 comprise a single desktop computer or a facility-based 

19 networked system of multiple desktop, or other computers. 
20 

21 Communications gateway-router 204 manages communications 

22 through these various media services and provides consistent 

23 interfaces to users at devices 200 and to host computer 

24 facility 206, regardless of which communication service 202 

25 is used. 
26 
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1 ■ As referenced hereinabove, host computer facility 206 can 

2 comprise a client-server system in which a file server or 

3 database management server, or cluster of such servers, 

4 manage data storage and traffic functions, providing high 

5 volume data availability to multiple intelligent clients 

6 linked, typically over a local area network, to the server 

7 or servers. 
8 

9 Exchanging data, programs and processing services across 

10 this system, user interface devices 200 and host computer 

11 facility 206 support applications such as the prescription 

12 management system of the invention, E-Mail services and any 

13 other desired applications, for example patient encounter 

14 management programs, diagnostic procedure management 

15 programs, and the like, in an analogous manner to 

16 conventional client-server supported operation of such 

17 applications. 
18 

19 Host computer facility 206 provides intelligent network 

20 services to user devices 200 and 201 and may support 

21 ancillary services, especially for example, as described 

22 hereinbefore, patient-directed data access control software. 

23 Prescriber-directed data access control software or 

24 organization-directed data access control software could 

25 also run in an application separated from the prescription 

26 management system, but is preferably integrated therewith as 
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1 a component of a user initialization routine. 
"2 

3 Conveniently, patient interface components of the patient- 

4 directed data access control software are run at separate 

5 stations from the point-of-care locations used by 

6 prescribers and are located, for example, in administrative 

7 or reception areas of health care facilities or managed care 

8 organizations. Here, data access rights may be read off a 

9 patient T s data access control card, and such cards may be 

10 issued, under control of software supplied by, and in 

11 communication with host computer facility 206. 
12 

13 , The level of software and data resident on interfaces 

14 devices 200 can be varied according to their physical 

15 capabilities and user or system administrator preferences. 

16 At a minimum, and for device redundancy, interface devices 

17 200 need have resident neither files nor software, beyond 

18 "what is supplied with the device off the shelf. 
19 

20 So long as the user interface device has an operating system 

21 and is communications-equipped, they may establish 

22 communication with host computer facility 206, using a 

23 separately supplied electronic address for that facility and 

24 may upload necessary program components and data files, 

25 including such personalized user profiles as have been 

26 established by the user's prior experience with the system 
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1 and which have been stored at the host computer facility 

"2 206, are called from a remote host computer facility 

3 supporting other users. 
4 

5 Neither such program components, nor data, need be stored on 

6 the interface device 200 but, where the device 200 has 

7 adequate storage capacity, it will be more convenient and 

8 faster-loading for a user to maintain configuration and user 

9 profile files, along with limited amounts of relevant drug, 

10 and possibly patient data, on the user's local interface 

11 device 200. Preferably, however basic system access 

12 software is required to be installed on the user device 

13 before system resources can be accessed. Such basic system 

14 access software can be activatable after reported loss or 

15 theft to disable system access capabilities and to render 

16 any stored proprietary data inaccessible to unauthorized 

17 users. 
18 

19 Host computer facility 

20 Host computer facility 206 provides full software support 

21 for user interface devices 200 and maintains complete 

22 program files for the prescription management system along 

23 with e-mail services and any other non-personal applications 

24 that may be needed by users of devices 200 beyond the basic 

25 operating systems and utilities, and the like, with which 

26 the devices are originally equipped. 
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1 Host computer facility 206 maintains databases of patient 

'2 information for patients encountered or whose records have 

3 previously been viewed by users of devices 200 in response 

4 to calls sent via host computer facility 206, (and logged by 

5 it for audit purposes) but, in keeping with the preferred 

6 practice of the present invention, host computer facility 

7 206 does not maintain patient records in permanent storage. 

8 It could however be used zo maintain patient record 

9 components that are source components to users of devices 

10 200 for which this particular host facility 206 is, at it 

11 were, their "home" facility, 
12 

13 Important functions maintained by the host computer facility 

14 206 are information locator databases and advanced directory 

15 and routing services, including the following: 

16 i) a user device and system registry enabling 

17 communications to be routed to the target user; 

18 - ii) a patient information directory service enabling 

19 access the system to access remote databases to 

20 retrieve patient record components for compilation 

21 of virtual patient records as described above; 

22 iii) archiving of transaction logs and records, and of 

23 audit logs; 

24 iv) patient drug formularies and formulary guidelines 

25 or locators to access same; 

26 v) libraries of alerts and other system displayed 
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1 



messages; and 



2 



vi) access control software and related data files for 



3 



patients, care providers and organizations. 



4 



5 Drug and condition lists and some drug information are also 

6 maintained on the host computer facility 206, but these are 

7 preferably either synchronized or refreshed at intervals 

8 (e.g. overnight) from source databases of such drug 

9 information. More detailed drug information (e.g. U.S. 

10 Pharmacopeia information) can be retrieved from remote 

11 databases by host computer facility 206. Host computer 

12 facility 206 also maintains directory services for accessing 

13 such drug related information, formularies, guidelines alert 

14 messages and the like and updates this data remotely from 

15 source databases maintained by the proprietors of the 

16 information. 



18 Also in addition, host computer facility 206 can off-load 

19 data-processing functions from interface devices 200, or 

20 conduct such functions in background to provide support for 

21 the relatively limited processing capabilities of devices 

22 200. 
23 

24 A further important function of host computer facility 206 

25 is to retrieve multiple elements of a single patient record 

26 from multiple heterogenous remote databases and to deliver 
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1 them to users for assembly into a virtual patient record by 

2 an interface device 200 or 201, in response to the user's 

3 call for that record. 
4 

5 Host facility 206 can reach out nationally, or 

6 internationally, for example across the INTERNET (trademark) 

7 to multiple remote databases such as remote databases 210 

8 shown on the right hand side of Figure 16, to provide to 

9 users of interface devices 200 data resources beyond (and 

10 potentially more current than) those available from direct 

11 storage in the device or at the host facility. 
12 

13 Communications 

14 Communication between host computer facility 206 and remote 

15 databases 210 will usually be via wire lines such as 

16 telephone, or local or wide area network communication via 

17 copper line, or optical fiber, or any other suitable 

18 communication medium. Clearly, host computer facility 206 

19 can access any remote third party database with which 

20 appropriate arrangements have been made, or can be made on 

21 line, and some possible source databases for patient records 

22 components are labeled as "HMO's, Hospitals Insurance, Drug 

23 Benefit Cos, Pharmacies, Labs and Independent Physicians". 

24 Drug information may be additionally sourced from 

25 pharmaceutical companies' research centers, reference 

26 libraries, or publishers and the like. 
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1 One or more pools of users of devices 200 and computers 201 

2 constitute a valuable professional audience and the system 

3 provides a valuable means enabling such third party database 

4 proprietors to become data publishers and electronically 

5 publish or post their databases or on the network to reach 

6 that audience. 
7 

8 Using recognizable common record element identifiers, for 

9 example patient identification numbers or drug identifiers, 

10 host computer facility 206 forages across available networks 

11 for similarly identified record elements to retrieve. 

12 Employing its information directory services as locators, 

13 host computer facility can retrieve a variety of data 

14 including patient-specific data, application-specific data 

15 (users preferences and the like) , organization-specific data 

16 (formulary guidelines, for example) and general drug or 

17 prescribing data, e.g. from MEDLINE. 
18 

19 To assist with compatibility problems with the legacy 

20 systems operating at remote databases 210 and to avoid heavy 

21 volumes of user calls, via the systems of the present 

22 invention, interfering with or slowing down the daily 

23 operations at the proprietary facilities supporting the 

24 remote data bases 210, this embodiment of the invention 

25 provides, at each of a limited number of remote databases 

26 210 known to be a significant source of patient record 
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1 elements, a dedicated data warehouse 212. Data warehouses 

'2 212 can be real or functional, depicting either actual 

3 physical embodiments of system-dedicated services located at 

4 the facilities of remote databases 210, or logical functions 

5 executed at the host computer facility 206. 
6 

7 Data warehouses 212, host computer facility 206, 

8 communications router-gateway 204 and communications 

9 services 204 are components of a conceptual integrating 

10 network 214 which brings users of devices 200 and 201 

11 transparent access together with the resources available at 

12 remote databases 210, and preferably gives those users a 

13 seamless appearance, as though data stored piecemeal at 

14 multiple remote databases 212 were directly available from a 

15 single file across a local area network. 
16 

17 To facilitate connection with heterogenous databases, and to 

18 give their proprietors fluent access across the network, it 

19 is preferred that the system provides uniform application 

20 programming interfaces, remote API T s 216 for use by third 

21 party developers. Compatible user API's 218 on the 

22 downstream side provide similar standardized connectivity 

23 with user devices 200 and 2.01. 

24 , - - 

25 Integrating network 214 and API's 216 and 218 permit easy 

26 system integration, allow third parties to develop end-to- 
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1 end communications solutions with standardized third party 

'2 communication across the network and a data "firewall" for 

3 security. 
4 

5 Data Warehouses 212 

6 Each data warehouse 212 maintains replicated copies of 

7 relevant data sets obtained by read-only access of remote 

8 databases 210, which data sets are maintained synchronously 

9 with updated source data at remote databases 210, or are 

10 periodically refreshed therefrom, preferably at frequent 

11 intervals. Data warehouses 212 can also provide search and 

12 retrieval facilities and, in particular, provide protocol 

13 interchange and reformatting capabilities to reformat or 

14 otherwise standardize data and communications across network 

15 214, for any application to use. Preferably, to facilitate 

16 compliance with the desired auditability of the transactions 

17 and data accesses of preferred embodiments of the invention, 

18 -data warehouses 212 screen data incoming from associated 

19 data warehouses 210 for date-stamping, and preferably, also 

20 time-stamping, of individual received data or record 

21 elements, and reject those that lack such stamps. 

22 Preferably also, the date stamp indicates origination, 

23 creation or updating of the data element, rather than being 

24 merely a date of entry of the data element into data- 

25 warehouse 212. 
26 
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1 Source data generated by point-of-care or other transactions 

2 at user interface devices 200 or computers 201, can be 

3 directly posted to remote databases 210 across network 214 

4 which bears two-way traffic. As will be apparent from the 

5 disclosure herein, remote databases also include data from 

6 other places, for example pharmacies, laboratories and 

7 testing facilities. 
8 

9 Communications gateway-router 204 also maintains a 

10 physician-device directory providing routing or access 

11 information needed to establish communication protocols with 

12 each individual physician. This device directory service 

13 can maintain an electronic address, a device identifier or 

14 device configuration, operating system information and user 

15 device communications protocols for each user device 

16 supported by the gateway-router. User ID T s can be listed 

17 separately and in preferred embodiments are accompanied by a 

18 prioritized listing of one or more device addresses where 

19 the user may be accessed. 
20 

21 Other temporary or permanent update means are provided to 

22 enable a user to access the host computer facility from more 

23 than one device, preferably using an address that is device- 

24 independent. , - 
25 

2 6 It will be understood that an individual host computer 
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1 facility 206 can serve one group of users that may, for 

"2 example, be defined geographically and may number from, for 

3 example, as low as 10 or 20 users in the early days of 

4 establishment of the facility to hundreds and thousands as 

5 the facility matures. To service more users or to service 

6 users in other geographical areas, additional host computer 

7 facilities 206 can be established as centralized or 

8 regionally distributed hubs. Such additional host computer 

9 facilities 206 will, in all likelihood, access many of the 

10 same remote databases 210. Preferably, switching or 

11 rerouting means are provided to optimize data traffic loads 

12 between multiple host computer facilities 206. 
13 

14 It will also be understood that a national or international 

15 network can be created by establishing a sufficient number 

16 of host computer facilities 206 in strategic locations, each 

17 serving a local client base of, for example campus or 

18 regional users, with interface devices 200, 
19 

20 Summary 

21 The foregoing description has emphasized an approach to 

22 therapy prescribing which records an association between a 

23 therapeutic agent (drug) and a condition or problem targeted 

24 for resolution or amelioration by the prescribed therapeutic 

25 agent. Significant benefits derive from organizing known 

26 therapeutic agents according to conditions for which they 
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1 are known to be effective, and emphasis has been placed 

2 herein on a drug selection and specification which begins 

3 with selection of a problem or condition to be treated, 

4 because this is be an appealing and beneficial approach in 

5 many circumstances. Frequently however, the physician may 

6 know exactly what drug they wish to prescribe, in which case 

7 they can proceed to a direct drug entry screen, and then 

8 specify the condition targeted by the prescribed treatment. 
9 

10 While emphasis has also been placed in the principle 

11 examples on the prescription of drugs, it will be 

12 appreciated that the invention can be beneficially applied 

13 to the specification of other therapies and technical 

14 remedies for example to the specification of surgical 

15 procedures, physical therapies and diagnostic testing. 
16 

17 Preferred embodiments of the invention include quick and 

18 easy routines for directly posting a drug to a prescription, 

19 without prior condition selection, such routines preferably 

20 being by-passed. In order to gain the subsequent 

21 historical review and outcome study benefits described 

22 herein, it is preferred to provide for inclusion of a 

23 treatment objective of the prescribed drug in the 

24 prescription record before completion of the prescription. 

25 The treatment objective can be rapidly selected from a 

26 system-supplied list of a patient's existing or historical 
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1 conditions, or through powerful system-aided selection of a 

2 new condition. While a default patient condition or 

3 problem may be suggested by the system for a particular 

4 prescribed drug, it is preferred that such default be 

5 actively confirmed by the prescribing user before being 

6 accepted by the system. 
7 

8 To accommodate direct prescribing by drug name, Drug field 

9 88 of the prescription creation screen of Figure 3, can open 

10 a personalized or customized user-activatabie drug list, or 

11 proceed to comprehensive system drug lists to enable rapid 

12 specification of familiar or unfamiliar drugs prior to 

13 condition selection. Drug dosage selection then proceeds as 

14 described above. Before leaving prescribing zone 44 of the 

15 prescription creation screen 39 the system can require an 

16 appropriate entry to be made in Condition field 86. 
17 

18 Other preferred embodiments enable the patient, the 

19 prescribing physician and the relevant organization to 

20 control the flow of their own data by predetermining access 

21 rights to that data. Every transaction can be stamped with 

22 a patient identifier, a prescriber identifier and, if 

23 appropriate, an organization identifier, as well as with the 

24 date and time of day. ; 
25 

26 Emphasis on preferred, historical or customized short lists 
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1 of drugs and conditions enables an attractive working 

* 2 environment to be provided even on relatively low power 

3 PDA's. Short list data may be maintained on the user device 

4 providing rapid responses in the user's most common 

5 prescribing situations- Less common situations entail calls 

6 to the host computer facility, in which circumstances delays 

7 of a few seconds while data is retrieved from the network 

8 are quite acceptable. 
9 

10 System requirements 

11 User software components of a currently preferred embodiment 

12 of prescription management system described herein are 

13 designed to run under an operating system that preferably 

14 supports a full or modified version of MS-DOS® (trademark, 

15 Microsoft Corporation) WINDOWS™ (Microsoft Corporation) or 

16 other systems with user-friendly graphical interfaces, for 

17 example Apple Computer Co.'s MACINTOSH (trademark) or NEWTON 

18 -(trademark) operating systems and General Magic's MAGIC CAP 

19 operating system. Other graphical environments can be used 

20 or are being developed and other embodiments of the 

21 invention may be suitably modified to optimize the 

22 application to take advantage of the unique characteristics 

23 of each such operating system environment. 

24 _ - 

25 The programming language used to write system software 

26 depends upon the environment of the various system 
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1 components. In their present stage of development, some 

"2 handheld PDA ! s require applications to be written with the 

3 tools provided by their respective operating systems such as 

4 NEWTON or MAGIC CAP (trademarks) . For other devices such as 

5 those supporting Microsoft's WINDOWS (trademark) operating 

6 system, including some PDA r s, a range of languages can be 

7 used including for example, popular programming languages 

8 such as Microsoft Corporation's "C" or Borland 

9 International^ "C++". For Apple Computer's MACINTOSH 

10 (TRADEMARK) -based systems, languages such as THINK 

11 (TRADEMARK) are appropriate. 
12 

13 The system is particularly advantageous when implemented on 

14 any of a variety of portable computer stations especially 

15 handheld units such as personal digital assistants and other 

16 personal information communicators equipped with wireless 

17 communicators. A preferred embodiment for mobile 

18 professionals comprises such a handheld unit with two-way 

19 radio or infrared communication facilities. Some such 

20 devices are referenced in a "BUYER'S GUIDE: PERSONAL DIGITAL 

21 ASSISTANTS" PC WEEK August 29, 1994, pages 89 and 94 the 

22 disclosure of which is hereby incorporated herein by 

23 reference thereto. 
24 

25 For compatibility with the currently rather limited 

26 performance specifications of such desirable handheld 
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1 devices the prescription management system of the invention 

2 is preferably designed to minimize the storage and 

3 processing requirements placed on the user's terminal and to 

4 off-load storage and processing to host computer facilities. 

5 Thus, the system's support architecture aims to supply to 

6 the user terminal only essential data required for screen 

7 displays and other user functions, on an as-needed basis, 

8 while the network stores applications and data files, for 

9 example at the host computer facility. 
10 

11 Modified Embodiments of the Invention 

12 While the invention has been described with a reference to a 

13 particularly valuable embodiment of a prescription 

14 management system, it will be understood by those skilled in 

15 the art that alternative embodiments of the invention can 

16 bring valuable benefits in their respective fields where 

17 informed choice is desirable and can be facilitated by 

18 interactive computer-assisted decision-making, especially in 

19 situations where decision-relevant data is or can be drawn 

20 from multiple heterogenous remote databases. 
21 

22 Some such possible applications of the invention are to the 

23 specification of laboratory tests and also in the veterinary 

24 field, and to non-pharmaceutical environments where -benefits 

25 such as valuable historical records and follow-up studies, 

26 as well as quality control improvements, can be obtained 
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1 from coupling diagnostic conclusions with specified problem 

2 solutions . 
3 

4 Thus, according to one such a modified embodiment of the 

5 invention, laboratory test information can be presented to a 

6 prescribing professional by first listing patient conditions 

7 which the professional wishes to explore more fully by 

8 specifying one or more specific laboratory tests, by 

9 reporting the laboratory result and suggesting further 

10 testing for differential diagnostics. The system then 

11 provides a selection of laboratory tests known to be useful 

12 in evaluating the relevant condition, that selection and 

13 organization of laboratory tests being made in a manner 

14 similar to that described for therapeutic drugs in the 

15 preferred embodiments herein, and moves on to create, select 

16 and order appropriate cost-controllable diagnostic testing, 

17 in a comparable manner to that described herein for creating 

18 a prescription. 
19 

20 For example, an analogous diagnostic application may provide 

21 cost-effective routes to rule in or rule out specific 

x 22 diagnoses. The specificity and sensitivity of individual 

23 procedures can be translated into positive predictive values 

24 and negative predictive values. By applying decision theory 

25 and analyzing probable outcomes of procedures or 

26 combinations of procedures in the light of the patient's 
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1 bio-characteristics and known conditions, diagnostic 

2 protocols can be worked up and maintained with current 

3 recommendations. Evaluation of the patient's history can 

4 enable pretest probabilities to be established and used to 

5 modulate the predictive value of one or more tests. Thus 

6 the patient's history can drive the selection and 

7 establishment of an optimal diagnostic test matrix for 

8 identifying a patient's condition or conditions with good 

9 specificity and confidence levels. 
10 

11 Test requirements relating to patient preparations, fasting 

12 for example, and sample collection can be system specified. 

13 By generating system-maintained identifiers (e.g. bar cede 

14 labels) for attachment to samples at the point-of-care, a 

15 chain of evidence for rigorous sample accessioning can be 

16 begun. 
17 

18 Thus, a range of possible conditions can be evaluated in a 

19 differential diagnosis format designed to rule in or rule 

20 out a target condition, or conditions, depending upon the 

21 results of specified tests. 
22 

23 Extensions into the veterinary field will be apparent to 

24 those skilled in the art in that instead of the physician 

25 user referenced herein, reference to a veterinarian : is 

26 appropriate, and the patient will be an animal such as a pet 
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1 dog or cat or valuable livestock, such as a steer or 

2 breeding pig or a race horse or breeding stallion. 
3 

4 Again, although the invention has been described in its 

5 preferred embodiments with reference to a physician user it 

6 will be apparent that other medical professionals, 

7 especially those having prescribing authority, can benefit 

8 from applications of it. 
9 

10 In a more general sense, the invention provides a service 

11 professional with significant new benefits, especially 

12 during a service encounter with a customer or client, in 

13 selecting, specifying or providing technical remedies to 

14 consumer problems. For example, in specifying automotive 

15 replacement parts a service technician can benefit from an 

16 automotive service management system according to the 

17 invention in which a database of replacement parts is 

18 classified according to the service problem for which the 

19 parts might provide a remedy. Thus, for a customer with the 

20 problem of break squeal, the system may provide a list of 

21 parts, for example, brake pads, brake pins, brake shims or 

22 brake rotors, any of which may provide a remedy to the 

23 customers problem of brake squeal. Existing systems permit 

24 a service technician, having once identified the type of 

25 part they need, to obtain a number or part price and 

26 inventory on that part for the customer's specific model of 
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1 car. 

'2 

3 However, known systems do not permit the professional to 

4 query the system by customer problems , nor do they provide a 

5 summary of all facets of a solution to a problem leading to 

6 a summarized cost of treatment. In addition the inventive 

7 system can provide access to technical literature on 

8 relevant problems, for example an explanation of the factors 

9 causing brake squeal which can be printed out for customers. 

10 This is a rather simple example. More complex examples will 

11 be apparent to those skilled in the automotive and other 

12 arts, especially as this art develops, with sophisticated 

13 engine management and other microprocessor controlled 

14 systems raising new problems and new technical solutions 

15 being required. The inventive system can provide customer 

16 problem lists useful for outcome analysis to drive the 

17 development of better cars. 
18 

19 Of great value in the automotive and allied fields, equating 

20 a parts supplier, such as a factory or warehouse distributor 

21 with a plan benefit company is the ability to provide new 

22 product descriptive and price information or updates from 

23 multiple sources dynamically, in real time as transactions 

24 are created. Noting the desire of a benefits company to 

25 apply practical selection guidelines in an unobtrusive 

26 manner to the prescribing process, an equivalent technique 
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1 can be used by car factories to help control warranty 

2 service decisions at their dealerships. 
3 

4 In another embodiment of the invention illustrating its 

5 generality, possible insurance vendors and coverage 

6 information may be classified according to customer problems 

7 so that, for example, an insurance agent may list different 

8 vendors and coverage providing specific technical remedies 

9 to a customers specific; problem, for example, a recent 

10 major automobile collision claim. The relevant novel 

11 supportive database could include information 

12 differentiating between parties at fault, collision damage, 

13 personal injury settlements and so on. In both these 

14 examples a problem history related either to the customer or 

15 to the customer's automobile can also be created. 
16 

17 It will be clear to those skilled in the art that use of the 

18 prescription management system described herein, employing 

19 carefully maintained databases of accurate, reliable 

20 prescribing data will produce high quality prescriptions 

21 free of many of the problems now plaguing prescription drug 

22 use. With confidence that a physician is prescribing 

23 appropriate, cost-effective .drugs selected from user- 

24 personalized lists which link to comprehensive condition and 

25 drug lists including the latest available drugs, and that 

26 the prescribed drug has been reviewed for contraindications, 
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1 patients benefit, oversight of the prescribing process by 

2 benefit companies and regulatory bodies can be reduced, and 

3 litigation resulting from prescribing errors will be 

4 reduced. Significant improvements in the quality of care, 

5 substantial savings and the elimination of waste can accrue 

6 to a national or regional health care system from widespread 

7 deployment of the inventive prescription management system 

8 described herein. 
9 

10 Physical embodiment of system software 

11 The foregoing specification, read with the accompanying 

12 drawings provides an extensive disclosure of, inter alia , 

13 various embodiments of systems and software facilitating 

14 professionals to select or specify technical products to 

15 solve practical problems, and also to create, or assist the 

16 professional to create, new products which will assist the 

17 professional or their client in achieving desired problem- 

18 solving goals. 
19 

20 It will be understood that the systems and software 

21 referenced herein include, either explicitly, or implicitly, 

22 software implemented on computers or other appropriate 

23 hardware, including user devices such as the personal 

24 digital assistants described herein, and such other 

25 intelligent data processing devices having a processor, data 
2 6 storage means and the ability to support an operating 
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1 system, with or without user interfaces (for example, file 

2 servers,), as may be useful in achieving the objectives of 

3 this invention. 
4 

5 Software components and applications embodying the invention 

6 can be distributed in electronic bit storage on magnetic, 

7 optical, bubble or other media, optionally in transportable 

8 form to be interactive with an electronic reading device, 

9 for example on computer or optical diskettes, or may be 

10 distributed over wired or wireless networks for storage by 

11 the recipient on such media. 
12 

13 Preferred embodiments of the invention provide such media- 

14 stored software in a commercial package accompanied by 

15 instructions in printed book or booklet form, for deployment 

16 of the software on particular embodiments of general purpose 

17 computer to cause same to operate as a special purpose 

18 computer, in accordance with the objectives of the 

19 invention. License agreements, and registration means for 

20 updating may also be included. Alternatively, the 

21 instructions may also be provided as data files. 
22 

23 It will further be appreciated that such media-stored 

24 software constitutes an electronic customizing machine which 

25 can interact with a magnetically or optically cooperative 

26 computer-based input device enabling the computer to be 
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1 customized as a special purpose computer, according to the 

2 contents of the software. To cause a computer to operate in 

3 such customized, special-purpose mode, the software of the 

4 invention can be installed by a user, or other, and will 

5 usually interact efficiently with the device on which it is 

6 resident to provide the desire special-purpose qualities, 

7 only after selection of configuration parameters. When so 

8 configured, the special-purpose computer device has enhanced 

9 value, especially to the professional users for whom it is 
10 intended. 

11 

12 While some illustrative embodiments of the invention have 

13 been described above, it is, of course, understood that 

14 various modifications will be apparent zo those of ordinary 

15 skill in the art. Such modifications are within the spirit 

16 and scope of the invention, which is limited and defined 

17 only by the appended claims. 
18 

19 Thus, while certain aspects of the invention have been 

20 disclosed as embodied in connection with a prescription 

21 management system, it will be apparent that they have 

22 broader application in other systems or environments. Some 

23 of these aspects are: dynamic assembly of records from 

24 source record elements retrieved across a network from 

25 heterogenous remote databases; requirements for those 

2 6 elements to be time- and date-stamped for retrospective 
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1 recreation of records from archival logs; physician-centric 

2 drug formularies; data-access control systems and software; 

3 the novel directory services described herein and associated 

4 online point-to-point e-mail and data retrieval systems; 

5 data retrieval networks with API-enabled end-to-end 

6 transparency; novel outcome studies , monitoring and alerting 

7 procedures, studies and related products; novel scheduled 

8 dosage drug packs and dispensing devices, and so on. 



